Upgrade from Sql 2000 to SQL 2005 creates unwanted schemas
June 28th, 2007Read the rest of this entry »
Deprecated: Assigning the return value of new by reference is deprecated in D:\www\1-2remember.nl\www\BLOG\wp-includes\cache.php on line 36 Deprecated: Assigning the return value of new by reference is deprecated in D:\www\1-2remember.nl\www\BLOG\wp-includes\query.php on line 21 Deprecated: Assigning the return value of new by reference is deprecated in D:\www\1-2remember.nl\www\BLOG\wp-includes\theme.php on line 507
In SQL Server 2000, a single configuration was available for the SQL Server Agent Proxy account. With SQL Server 2005, now 11 different proxies are available for each of the SQL Server Agent subsystems. This offers a great deal of flexibility and greater security for each of these subsystems for logins and roles that do not have administrative rights to SQL Server, but need to manage SQL Server Jobs.
In order to setup the SQL Server Agent Proxy, it depends on an existing credential at the SQL Server level that maps to a Windows domain login in SQL Server. By default SQL Server does not ship with any predefined credentials, so to set one up in Management Studio for the purposes of SQL Server Agent Proxies, navigate to the root folder| Security folder | Credentials folder | right click on the Credentials folder | select the New Credential option and then enter the name, identity (Windows domain login in SQL Server) and password.
Jobs which run for a specific application should be executed by an account of that application. This will probably be a function account. The following steps should be taken in order to let a non-SysAdmin execute a job.
1. Open the Management Studio and connect to the database instance your job is running on.
2. Select the “Properties” of you Job.

3. In the Owner field fill in you application’s User which should run this SQL Server Agent Job.