2

It's a new installation of SQL Server 2019 Standard, on Windows Server 2019 Standard.

I've created a maintenance plan using NT SERVICE\SQLAgent$HPIEF (named instance) but the execution fails reporting:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {571FCE7E-C4EB-41CF-B9D1-1CBCBFC6D2BD} and APPID {82F02F0C-0E3A-472E-BAA5-0BC0AE548818} to the user NT SERVICE\SQLAgent$HPIEF SID (S-1-5-80-1440956658-2197097766-264727899-1866809211-3642620551) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

I have a similar installation of SQL Server 2014 Standard, on Windows Server 2012, and the maintenance plan works there just fine.

What's different? what do I need to do to the SQLAgent account or the service to get the issue fixed?

1 Answer 1

4

Short answer:

Unless your SSIS job is failing, you can (and should) ignore that error.

Long answer:

That is the CLSID and APPID for the MsDtsServer150 local service (English display name "Microsoft SQL Server Integration Services 15.0"). That is the legacy Integration Services service, which runs as a COM server in it's own Windows service and communicates with client applications using DCOM. It is distinct from Integration Services server, which is the one first introduced in SQL Server 2012 that runs as part of the Database Engine and uses the SSIS Catalog (SSISDB).

When SQL Server Agent executes an SSIS job step, it tries to activate the legacy MsDtsServer150 service (for SQL Server 2019 - the version at the end of the service name is different for earlier versions of SQL Server). It does this regardless of whether the legacy service is actually needed for that particular job step. If that job step doesn't use the legacy service (e.g. if it is running a package that is stored in SSIS Catalog and therefore uses Integration Services server instead), the failure to activate the service won't cause any problems, other than the logging of the error to the System event log (which can unfortunately cause a fair amount of noise in the event log if it is a job that runs frequently).

The failure to activate the legacy service could be a permissions issue (like the message says). I believe it could also be due to the legacy service being set to Disabled (if I remember correctly from when I first looked into this error years ago), but I don't have a server I can test this on at the moment. Having the legacy service set to Disabled is a best practice if you do not have any legacy jobs that require it; it is not needed if all of your SSIS jobs / packages are deployed and run through the SSIS Catalog or manually through a GUI or DTExec.

If you don't have any jobs that require the legacy service, I'd suggest not messing with the DCOM permissions, and leaving the legacy service set to Disabled (or changing it to Disabled if it is not already set that way, after first testing this in a non-production environment, of course). You can just ignore this error being logged in the System event log, with no ill effects.

If you do have very old jobs that require the legacy service (i.e. haven't been updated for SSIS Catalog), and the jobs are currently failing to run, you can follow these instructions to change the permissions:

  1. Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying certain settings in the registry.
  2. In the Component Services dialog, expand the Component Services > Computers > My Computer > DCOM Config node.
  3. Right-click Microsoft SQL Server Integration Services 15.0, and then click Properties.
  4. On the Security tab, click Edit in the Launch and Activation Permissions area.
  5. Add users and assign appropriate permissions, and then click Ok.
  • NOTE: You'll need to do this for the job proxy account(s) used for each SSIS job step that has a dependency on the legacy service, or for the SQL Server Agent service account if there are any SSIS job steps with such a dependency that do not use a proxy account.
  1. Repeat steps 4 - 5 for Access Permissions.
  2. Restart SQL Server Management Studio.
  3. Restart the Integration Services Service.

Again, this should ONLY be done if you've confirmed you have a specific dependency on the legacy Integration Services service. In that case, you should also start planning on updating those jobs to go through the Integration Services server / SSIS Catalog instead, as it was introduced as the replacement for the legacy service almost 10 years at this point.

These instructions are slightly adapted from the ones Microsoft provides in the documentation here. Please note that the information in multiple parts of that page is out of date. Many of the statements it makes about when the legacy Integration Services service is required were written before Integration Services server was introduced, and are only applicable if you still have specific dependencies on the legacy service.

Applicability

This question is relevant to SQL Server 2012 and later, but each version will have a different CLSID and APPID for the corresponding version of the legacy Integration Services service. To aid anyone trying to search for further information about this, I've listed the values that will appear in the event log message for each major version of SQL Server, up through SQL Server 2019.

Version Legacy SSIS Service Name CLSID APPID
SQL Server 2012 MsDtsServer110 {FDC3723D-1588-4BA3-92D4-42C430735D7D} {83B33982-693D-4824-B42E-7196AE61BB05}
SQL Server 2014 MsDtsServer120 {806835AE-FD04-4870-A1E8-D65535358293} {EE4171E6-C37E-4D04-AF4C-8617BC7D4914}
SQL Server 2016 MsDtsServer130 {2DC39BD2-9CFF-405D-A2FE-D246C976278C} {DB336D8E-32E5-42B9-B14B-58AAA87CEB06}
SQL Server 2017 MsDtsServer140 {E0628A3F-D40D-4C78-87B9-98733CDF11F2} {347F1A3E-7950-45F6-8681-43C056BDE1BD}
SQL Server 2019 MsDtsServer150 {571FCE7E-C4EB-41CF-B9D1-1CBCBFC6D2BD} {82F02F0C-0E3A-472E-BAA5-0BC0AE548818}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.