Tag Archives: SQL

SCCM 1511 Driver Migration Fails

While migrating drivers from SCCM 2012 to SCCM 1511, the migration can fail with the following error message:

Couldn't find the specified instance SMS_CategoryInstance.CategoryInstance_UniqueID='DriverCategories:

This occurs given the following scenario:

  1. A driver is added to SCCM
  2. A category is assigned to the driver
  3. The category is deleted from the driver
  4. The migration job attempts to migrate the driver to a new SCCM environment

Consider the following error message:

Couldn't find the specified instance SMS_CategoryInstance.CategoryInstance_UniqueID='DriverCategories:78266da1-ebac-4c12-b2c8-89451383b03e

An In-depth analysis shows that the driver category does not appear in the WMI Class SMS_CategoryInstance:

Get-WmiObject -Namespace $Namespace -Class SMS_CategoryInstance -Filter "CategoryInstance_UniqueID = 'DriverCategories:78266da1-ebac-4c12-b2c8-89451383b03e'"

Returns Null, but a SQL query indicates that the Category Instance still exists:
SELECT * FROM CI_CategoryInstances

WHERE CategoryInstance_UniqueID
LIKE ‘%78266da1-ebac-4c12-b2c8-89451383b03e%’

 

Returns the following:

CategoryInstanceID CategoryInstance_UniqueID CategoryTypeName DateLastModified SourceSite ParentCategoryInstanceID IsDeleted rowversion
16777602 DriverCategories:78266da1-ebac-4c12-b2c8-89451383b03e DriverCategories 2015-07-27 11:52:33.000 CM1 NULL 1 0x000000000A36B34D

Take note of the “IsDeleted” column – set to True

So, at this point, WMI reports that this category no longer exists; however the category is still in the SQL Database, though this is not the root of the problem.

Now consider the WMI Class SMS_CategoryInstanceMembership:
This class contains a correlation of Objects to CategoryIDs.  This is not limited to Driver <-> Driver Category correlation.

The true bug seems to be that when a driver category is removed, the entry for that driver category in the  SMS_CategoryInstanceMembership class is not removed.  In order to fix this, and have a successful migration, we need to manually remove the CategoryInstanceMembership object for any drivers that were assigned a now deleted category.

to Fix:

  1. Fire Up SQL Server Management Studio
  2. Create a New Query, and select your Site Database
  3. For each failing driver entry (as seen in “C:\Program Files\Microsoft Configuration Manager\Logs\migmctrl.log”),
    1. Run the following SQL Query:
      SELECT * FROM CI_CategoryInstances
      WHERE CategoryInstance_UniqueID
      LIKE '%c6e9d9e3-1371-46ba-b7f1-bb46c5b6bc06%'
    2. Note the CategoryInstanceID  (should be like 16777601)
    3. On your SCCM Server, from an administrative PowerShell run the following code to remove the association, substituting the CategoryInstanceID you discovered in step 3-2:
      Get-WmiObject -Namespace $Namespace -Class SMS_CategoryInstanceMembership -Filter "CategoryInstanceID = '16777601'" | Foreach-Object {
      Remove-WmiObject -InputObject $_
      }
  4. Repeat the above section for each unique CategoryInstance_UniqueID listed in the “C:\Program Files\Microsoft Configuration Manager\Logs\migmctrl.log” file.
  5. When complete, retry the migration, and examine for any additional missing CategoryInstance_UniqueID errors.

References (In order of usefulness):

  1. http://cm12sdk.net/?p=981
  2. https://www.reddit.com/r/SCCM/comments/34b18i/delete_multiple_driver_admin_categories/
  3. https://technet.microsoft.com/en-us/library/hh849820.aspx
  4. https://technet.microsoft.com/en-us/library/dn151092(v=sc.20).aspx

SQL AlwaysOn Availability Group User Accounts

When creating SQL 2014 AlwaysOn Availability Groups, careful attention is required when provisioning the logins on each member server.

While the databases may contain user accounts for the appropriate members, the cluster member servers may not contain login information for said users. This can result in a seemingly “happy” fail over cluster (according to the dashboard in SQL Server Management Studio), but upon fail over, much pain will occur.

From a 10,000 foot view, the Logins on each server need to have the same SID, Username, and Password.

More detail (along with a script to rectify any “on-noes” that may have occurred in your environment): https://support.microsoft.com/en-us/kb/918992

This page contains some best practices for avoiding the described issue: https://aalamrangi.wordpress.com/2015/02/09/avoid-orphan-users-in-alwayson/