Tell me more ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.
up vote 1 down vote favorite

I have a SQL Server instance that runs 5 scheduled tasks each night, each of which run SSIS packages.

These packages have been running for years and the associated steps run via a Proxy Account (PackageExecutor). PackageExecuter is associated with a SQL Credential that was a former domain admin account.

Soon, the domain associated with this admin account is going to be shutdown. I have to use a new account, on a new domain, as the admin account associated with my roxy, PackageExecutor. When I created a new Credential for the new Admin account and associated it with PackageExecutor, I started to get the following error when I tried to run one of my SQL jobs as a test:

Unable to start execution of step 1 (reason: Error authenticating
proxy *Domain\Admin_Account*@*fully.qualified.domain.com*, system
error: Logon failure: unknown user name or bad password.).  The step
failed.

If I'm understanding this reasonably explicit error, what it's telling me is that the Credential accounts, associated with my proxy is in correct. How do I validate this?

I know that this account is legitimate-- I've already associated it with every associated server group, I've made it a sysadmin user on the server.

What could be causing this problem?

To be clear, I haven't mis-typed the account name or the password associated with the Proxy Credential. However, when I entered the account name Domain\Admin_Account and clicked the Check Names button, SQL Server automatically transformed the User ID to the fully-qualified version. I'm not sure if this has anything to do with this problem.

I'm at a bit of a loss. I've given my credential account full access to everything that I can think of. What might I need to do to get this to work?

UPDATE

Sorry, one more quick mention. I've found this MSDN kb article. Resolution method #1 is what I've been doing for years. The others don't seem to apply, or I'm missing something. Any tips or clarification would be beneficial.

share|improve this question
Try using DOMAIN\Admin_Account (as you typed it) for the credential identity and see what happens. – Jon Seigel Jul 24 '12 at 15:33
If I double-click on the Credential and remove the @domain.blah.blah.blah.com portion, it will save/accept the credential, but when I execute the package, I get the same response as mentioned above, accept, the name of the account in the error message has changed to reflect my removal of the @domain.com. – RLH Jul 24 '12 at 15:37
You probably saw my comment edit -- I realized that Management Studio will accept anything for the identity and password. It doesn't get validated until something uses it. – Jon Seigel Jul 24 '12 at 15:40
Is there any other way of validating it. Maybe some way of checking it and getting a more explicit or appropriate error? – RLH Jul 24 '12 at 15:41
I believe I have solved this problem but I don't know why. If this makes sense (@Jon Seigel) feel free to post an answer explaining what's going on. Otherwise, tomorrow after the scheduled tasks exec, I'll post an answer regarding my discovery. In short, instead of using SSMS on my PC, I remoted into the server logging in with the account associated with the new credential. I removed the cred, created it again (this time SS didn't at the @domain.com) and then I attempted a test execution of one of the jobs. It worked?! Apparently this changed something and helped SS resolve the account. – RLH Jul 24 '12 at 15:59

Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.