Troubleshooting Security for Packages during SCCM 2007 to 2012 R2 Migration

Summary

In a recently opened case, a customer reported that he was receiving errors when attempting to migrate content from his SCCM 2007 environment to his SCCM 2012 R2 infrastructure. When looking in migctrl.log, the following error was found:

ERROR: [MigMCtrl]: FAILED to EXECUTE job. error = Unknown error 0x80131500, 80131500 SMS_MIGRATION_MANAGER 6/17/2014 7:32:23 AM 6904 (0x1AF8)

This error would occur whenever he attempted to migrate a test package between his two environments.

Troubleshooting Steps

To resolve this issue, it was necessary to review the customer’s smsprov.log file. Because this file is overwritten so rapidly, the recommendation was for him to run an attempted migration and immediately get a copy of smsprov.log for review. We were specifically looking at this log on the SCCM 2007 Site Server since this was the source server for his migration effort.

In this case, the customer followed the guidance and submitted smsprov.log for review. They made me aware of the timestamp when they started the migration effort to help target the correct portion of the log.

In reviewing smsprov.log, I uncovered an entry similar to the following:

[13988][Thu 06/26/2014 06:28:17]:Execute WQL =SELECT * FROM SMS_Package WHERE PackageID='<Package ID>'

[13988][Thu 06/26/2014 06:28:17]:Results returned: 0 of 1

This information told me that Configuration Manager 2007 had attempted to access the specific package  listed using the WQL query listed. When the results returned = 0, this means there is a permissions problem somewhere.

NOTE: In every query, even if there are no issues of any sort, the number of results returned will always be listed as 1 less than the total possible results (for example, 18 of 19). This is normal. In this case, however, since no results were returned I knew the issue was related to permissions.

Typically in smsprov.log, when a WQL query is listed, the next line in the log will list the SQL query which is the equivalent of WQL. In this case, it did not but I was able to reconstruct the correct query, which was as follows:

SELECT * FROM SMSPackages WHERE PkgID = '<Package ID>’

From this point, our troubleshooting efforts were:

1. Run the SQL query directly in SQL Server Management Studio (SSMS) against the SCCM 2007 database in order to determine whether the package was present in the database to begin with
2. If the query returned the package in the results, we would know that the issue was with the permissions available for the SMS Provider to access the SQL database, and we would need to troubleshoot the permissions assigned to the package itself in SCCM

We ran the query in SSMS and the results did return the package as expected. From here, we turned to the package itself in Configuration Manager. We needed to find out whether the customer’s migration account was configured with the correct permissions.

I asked which account they had configured as the ConfigMgr 2007 Migration User Account. The customer indicated he did have one and told us the name of the account. In the example screenshot below from my lab, the 2007 Migration account has been set up as ‘CM12 Migration’

The customer further indicated he had created a Global Group in Active Directory Domain Services (AD DS) with administrative permissions in SCCM 2007. This was the group to which he had added the migration account.

We next opened the SCCM 2007 Admin Console and navigated to Computer Management\Software Distribution\Packages as shown in the screenshot below.

We selected the package listed in the SQL Query and chose Security from its properties pages.

In reviewing the Class and Instance security rights, we could see that the customer had assigned the SCCM 2007 administrative group similar to how the example group is shown in the screenshot above. The group appeared to have the correct permissions, so the migration should have worked.

At this point, because the migration still was not working, we asked the customer to verify membership in this administrative group. He went to Active Directory Users and Computers and inspected the group by opening its properties and going to the Members tab.

As shown below, the migration account was not actually a member of the administrative group that customer had configured.

The customer confirmed that his migration account was not a member of any other groups which had been assigned to this package.

At this point, the customer added the migration account and ensured proper Class and Instance rights once again. Once this was done, he kicked off his migration again and the package migrated successfully.