Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

MSDTSServer Expand / Collapse
Author
Message
Posted Tuesday, July 10, 2007 8:41 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, September 9, 2013 8:12 AM
Points: 137, Visits: 297

  I have some question concerning a problem we had.  Sorry for the size of this post, but I need to give some backgroud to the current situation.

   My shop is currently running a number of virtual servers using VMWare.  While many of these were copied from physical servers, a few were created as new servers.  Due to a 'problem' with VMWare, these new servers were created with duplicate network SID numbers.  Over the last weekend, July 7-8, Our network group changed the SIDs for these machines.  Only four of these machines had SQL Server installed(and the DBAs were not informed of this work). Two of these were SQL Server 2000 and two were 2005.


   After the SID was changed, the SQL Agent would not start on the 2005 boxes. The SQL Agent logs gave the following errors:

07/06/2007 20:46:18,,Information,[098] SQLServerAgent terminated (normally)
07/06/2007 20:46:18,,Error,[298] SQLServer Error: 15247<c/> User does not have permission to perform this action. [SQLSTATE   42000] (DisableAgentXPs)
07/06/2007 20:46:18,,Error,[000] Error creating a new session
07/06/2007 20:46:18,,Error,[298] SQLServer Error: 229<c/> The INSERT permission was denied on the object 'syssessions'<c/> database 'msdb'<c/> schema 'dbo'. [SQLSTATE 42000]
07/06/2007 20:46:18,,Error,[298] SQLServer Error: 229<c/> The EXECUTE permission was denied on the object 'sp_sqlagent_get_startup_info'<c/> database 'msdb'<c/> schema 'dbo'. [SQLSTATE 42000]
07/06/2007 20:46:18,,Error,[298] SQLServer Error: 229<c/> The EXECUTE permission was denied on the object 'sp_sqlagent_has_server_access'<c/> database 'msdb'<c/> schema 'dbo'. [SQLSTATE 42000] (ConnIsLoginSysAdmin)

Event viewer gave the following message:

SQLServerAgent could not be started (reason: Error creating a new session).


   After investigating the problem, it was determined that, even though the services for SQL Server were running under domain accounts, these account had been placed in the local groups that were created during the instalation proccess.  Since these were local groups, the SID of the group in Windows was now different from the SID of the group as defined in SQL Server.  We deleted the groups from SQL Server and recreated them, which placed the new SID into the syslogin table.  Even though it was only the agent giving us problems, we deleted and recreated the groups for both the agent and SQL Server.

   Last night, July 9, the maintenance plan job for backing up the system databases failed.  When I checked the files, the backup files had been created, but the log entry in the LOG directory had not been written. The following message was found in the Event viewer for DCOM:

 The application-specific permission settings do not grant Local Launch permission for the COM Server application with CLSID
{ABF05265-635E-44B0-A28F-AEA45247ACA0}
 to the user DDPOKDOM\SQLAgentService SID (S-1-5-21-520107568-192953301-624655392-6649).  This security permission can be modified using the Component Services administrative tool.

  After one of our network admins looked at the problem, he found that the permissions were missing for an app called MSDTSServer.  After adding permissions, the job worked.  The maintenance plan job for backing up the user databases did not fail. 

My questions are:
What is MSDTSServer?  I have looked in BOL and online through Google and cannot find any definition for this app.
Why did only one maintenace plan job fail?
Are there any other apps or components that we need to check for the change of the server SID?

 

Post #380321
Posted Tuesday, July 10, 2007 1:29 PM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Friday, September 21, 2012 1:52 PM
Points: 696, Visits: 743

If, instead of searching for 'MSDTSServer', you search for MS DTS Server, you will have much greater success. 

As to why only one plan failed, it may have to do with the way it was configured initially, the way the duplicate IDs were resolved, or the nature of the plan itself.  It could be that only this plan involved DTS Server, where the conflict arose.  Or only this one plan didn't get the proper mapping - this could have been a network admin's oversight (aka ooopsie) - it was resolved for all but this one before you were involved.

No answer for your last question from me...  Good luck going back and recreating the sequence of events (if you want to?), to determine what happened and what went wrong.  I think it was probably an honest, human error.

Post #380431
Posted Thursday, May 29, 2008 3:38 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 3:51 AM
Points: 1,037, Visits: 1,112
MsDtsServer is the DCOM application name for: Microsoft.SqlServer.Dts.Server.DtsServer
better known to its friends as CLSID ABF05265-635E-44B0-A28F-AEA45247ACA0
You can discover this by searching for the CLSID in the registry.

I have a similar permissions problem. Whenever a Maintenance Plan runs to backup a database or log, I get 2 DCOM errors, Event ID 10016, which is the same as the error you posted.

I can see how to fix the permissions, for example a nice explanation at:
http://www.cleverworkarounds.com/2007/10/25/dcom-fun-with-sharepoint/

In my current, standard set up, only Administrators and SYSTEM have "Local Launch" permissions. Adding local launch permissions to the domain user listed in the Event ID, solves the problem. My SQL Server and SQL Server Agent services both run under the same domain user account, so I am unsure which service requires the DCOM permissions. [Perhaps this is another reason to run the 2 services under different credentials.]

Is this a normal problem for an MSSQL Instance which runs under the credentials of a non-local-administrator?

I am also curious as to what exactly is going on in the background with DCOM. The Maintenance Plans complete successfully, with no errors. The only error is logged in the System Event Log. If the Maintenace Plan completes successfully, what is the DCOM local launch error related to?

The backups are being saved to a NAS, but the NAS drive is presented to the OS as a local drive, so I can't imagine that RPC with DCOM is required. Also, files are written correctly.... Any ideas?

Thanks,
Andy
Post #508263
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse