March 21, 2012 at 2:01 am
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user 'domain\domain user', error code 0xffff0002. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
This is the error log.
Please help me if you have the same issue.
March 21, 2012 at 8:34 am
Try to use a valid Login ID for the SQL JOB (Owner) Use either the SA Account or account with high Priviliges. (Change Owner to SA or etc)
Maninder
www.dbanation.com
March 21, 2012 at 8:44 am
If it literally has "domain\domain user", then that's probably the problem right there.
Otherwise, it's either not finding the specific group/account, or having trouble connecting the the specified domain server.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
March 21, 2012 at 7:49 pm
Any solutions?
March 22, 2012 at 5:25 am
Change the job owner to SA or Similar and verify the job...
Maninder
www.dbanation.com
March 23, 2012 at 7:41 am
Johnny Lan (3/21/2012)
Any solutions?
Yes. Verify connection to the domain listed, and verify the user/group listed.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
July 20, 2012 at 7:15 am
I'm experiencing the same errors. The domain account used is set as a server admin and as sysadmin.
Setting the jobs to run under 'sa' is a workaround, but best practice is not to use 'sa' and have to be reset everytime a maintenance plan is updated.
September 13, 2013 at 2:33 pm
It doesn't seem to be contrary if you take into account that the sa is a disabled account. Technically speaking it means "run under the service account", but to do so, we reference it with an account labeled "sa".
I may not have it completely right but that's the gist I get. The pain of changing all the jobs over to sa is understandable. Perhaps there should be something in Connect.Microsoft.com to suggest that it become a best practice and that the interface do it for us when we create the job if it runs under a service account.
If nothing else, it poses job security as it doesn't seem to be part of general knowledge that domain ownerships cause problems later on down the line. I try my best to get jobs and maintenance plans out of my name [as the dba] before I leave a position so the new guy coming in doesn't need to reassign the job nor cuss me out for leaving things in such a mess - as would be the case as soon as my domain name is removed from the AD and all the jobs fail where file rights are an issue. This also assumes that the service account has similar file rights, of course.
Jamie
December 2, 2014 at 12:05 pm
To resolve this issue:
-Launch Microsoft SQL Server Management Studio and connect to the database.
-In the Object Explorer, navigate to SQL Server Agent > Jobs.
-Right click the maintenance plan that you used during the initial creation of the job and click Properties.
Note: The maintenance plan has the format MaintenancePlan_Name.Subplan_x.
-Navigate to Job Properties > General Page.
-Set the value of Owner to SA.
-Click OK.
December 12, 2014 at 2:09 pm
Hi,
I think the error code is related with the credentials and the proxies.
Did you set up the Proxy ?
When you click in the SQL server Agent platform you will see some displayed folders. One of those is Proxies--> SSIS Package Execution-->Right Button-->New Proxy.
There you have to set up a Proxy with the features and permissions to run the SSIS Projects with your credentials (First see if you have credentials assigned to your profile\domain).
Later you will have connect to the Integration Services and create a folder to host your package:
Click on Stored Package Folder-->MSDB->Right button-->New Folder.
And the last one is save your package in that folder using the package from the visaul studio clicking on File-->Save copy of package.dtsx as-->Package Location-->SSIS package storage and there you have to save it the server and the folder that you have created there.
Let me know if this works for you!
July 21, 2015 at 12:22 pm
I have been running SQL jobs using domain account. It ran yesterday.
It fails today with this error. My infrastructure team said they didn't change anything
and I wasn't working yesterday. I have not been using the SSIS package Execution under Proxies
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply