Permissions

Permissions #

  • The application itself doesn’t need any special permissions for itself. It does require the user running to be in the sysadmin role. If you connect using a SQL Server login, that login needs to be in the sysadmin role.
  • If you connect to a target and aren’t in the sysadmin role, the target is skipped.

Multiple Accounts #

If you use multiple accounts, with different permissions on different instances, consider the following scenarios:

  • One account, one domain - Everything should work just fine.
  • Two accounts, one domain, all can connect - Typically this means one read-only account and one sysadmin account. Assuming both accounts have read-only permission, when running as a read-only account, it will skip the targets it can’t modify. This is often used where one account can administer development and one can administer production.
  • Two accounts, one domain - If the accounts that are sysadmin on some instances can’t connect to all instances you’ll need to filter by Roles when running as different accounts.
  • Multiple domains - See the section on Domains in the PRO Edition.