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 Tags when running as different accounts.
• Multiple domains - See the section on Domains in the PRO Edition.