November 10, 2009 at 2:16 pm
We have a windows scheduled task that runs a every minute using "domain name\machine name$" for its credentials. Usually the jobs runs successfully, but every so often it fails with: Logon failed for NT AUTHORITY \ ANONYMOUS LOGON.
The job itself is a SAS job that has two steps. It runs on ServerA.
The first step connects to a SQL2005 database ServerB (Windows 2003). This step ALWAYS works. The second step connects to a SQL2000 database on ServerC (Windows 2000). This is the step that fails intermittently.
All 3 servers are in the same domain.
The connection strings within the jobs steps are set up as follows, one per server:
(INIT_STRING='Provider=SQLOLEDB.1;
Integrated Security=SSPI;
Persist Security Info=True;
Initial Catalog=dbname;
Data Source=servername;'
schema=dbo);
After the job fails, it works for a while - anywhere from 20 minutes to more than an hour - and then fails again on the SQL 2000 connection. It seems like the failures happen sooner when there is heavy traffic, but we haven't really confirmed that.
Does anyone know why it randomly "drops" its machine name and ends up with NT AUTHORITY \ ANONYMOUS LOGON?
November 10, 2009 at 2:44 pm
I wonder if the problem could be Active Directory related. If it is having problems getting a timely response from its preferred DC then it may fail. Are there any other problems with the domain around the time the job is failing to indicate anything else? Error logs on either of the two servers that show AD/Network problems or errors on the preferred DC that could indicate problems?
Joie Andrew
"Since 1982"
November 10, 2009 at 8:48 pm
unixbomer (11/10/2009)
I wonder if the problem could be Active Directory related. If it is having problems getting a timely response from its preferred DC then it may fail. Are there any other problems with the domain around the time the job is failing to indicate anything else? Error logs on either of the two servers that show AD/Network problems or errors on the preferred DC that could indicate problems?
It is AD because Win2k and Win2003 uses two different profile objects so the easy solution is to add that account used for the scheduling in SQL Server 2000 in security under management and in the database. The other option is to tell system admin to script the profile object so all permission is resolved in all servers of the domain.
Kind regards,
Gift Peddie
November 11, 2009 at 9:39 am
add that account used for the scheduling in SQL Server 2000 in security under management and in the database.
Thank you both for your replies. GP - I added that account to the 2000 server when they first added the job.
I had them show me the actual scheduled task this morning, and I saw where the task is actually running under NT Authority\System. I do not have the NT Authority\System account as a login on the 2000 server. There is a NT Authority\System login on the 2005 as public, but is not a user on any of the databases.
So... do I need to add the NT Authority\System account to the 2000 server in addition to the DomainName\MachineName account?
November 11, 2009 at 3:25 pm
Marcia Q (11/11/2009)
add that account used for the scheduling in SQL Server 2000 in security under management and in the database.
Thank you both for your replies. GP - I added that account to the 2000 server when they first added the job.
I had them show me the actual scheduled task this morning, and I saw where the task is actually running under NT Authority\System. I do not have the NT Authority\System account as a login on the 2000 server. There is a NT Authority\System login on the 2005 as public, but is not a user on any of the databases.
So... do I need to add the NT Authority\System account to the 2000 server in addition to the DomainName\MachineName account?
That is very good question because that account in Win2k may either not exist or is called something else but that account and a domain user account with relevant permissions must be added into SQL Server 2000 and that includes database because passing permissions was not easy in Win2k. So you could start with the NT Authority on the server level and test but I think it may fail with heavy load. The SYSVOL in Win2k and Win2003 causes permissions and object issues I have not used it but I read in Win2008 RC2 Microsoft have provided a fix.
Kind regards,
Gift Peddie
November 12, 2009 at 11:21 am
Google: Sql Server service principal name
A.J.
DBA with an attitude
November 12, 2009 at 4:22 pm
A.J. Wilbur (11/12/2009)
Google: Sql Server service principal name
This is the SQL Server principle name MSDN page and the reasons for the problem which is Windows 2000 security as related to SQL Server is not covered and the account name in Windows 2000 which is needed is also not covered.
http://msdn.microsoft.com/en-us/library/ms191153.aspx
Kind regards,
Gift Peddie
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply