OfflineServicing fails if you have 'NO_SMS_ON_DRIVE.SMS' on your ContentLib drive.
Hi Folks,
I recently came across an issue with offline servicing in ConfigMgr2012. The issue was a bit obscure initially but a logical approach cracked it soon.
Offline Servicing fails with following error -
OfflineServicingMgr.log
____________________________________________________________________
Mounting image at index 1. Image file='C:\ConfigMgr_OfflineImageServicing\TCM0012B\Win7SP1_Office10_NET40_x64_10_02_2012.wim', MountDirectory='C:\ConfigMgr_OfflineImageServicing\TCM0012B\ImageMountDir', ImageFileType='WIM', Mode='ReadWrite'SMS_OFFLINE_SERVICING_MANAGER 29/11/2013 10:44:20 AM 18772 (0x4954)Image OS information : MajorVersionMS = 6, MinorVersionMS = 1, MajorVersionLS = 7601, MinorVersionLS = 18015 SMS_OFFLINE_SERVICING_MANAGER 29/11/2013 10:47:23 AM 18772 (0x4954)SQL>>>set quoted_identifier on;set ansi_warnings on;set ansi_padding on;set ansi_nulls on;set concat_null_yields_null on;set arithabort on;set numeric_roundabort off;set DATEFORMAT mdy; SMS_OFFLINE_SERVICING_MANAGER 29/11/2013 10:47:23 AM 18772 (0x4954)SQL>>>>> Done. SMS_OFFLINE_SERVICING_MANAGER 29/11/2013 10:47:23 AM 18772 (0x4954)SQL>>>select distinct cpkg.Content_ID, ContentSubFolder, FileName from vCIAllContents cont join CI_ContentFiles cf on cf.Content_ID=cont.Content_ID join CI_ContentPackages cpkg on cpkg.Content_ID=cont.Content_ID join SMSPackages pkg on pkg.PkgID=cpkg.PkgID where CI_ID=16791696 SMS_OFFLINE_SERVICING_MANAGER 29/11/2013 10:47:23 AM 18772 (0x4954)SQL>>>>> Done. SMS_OFFLINE_SERVICING_MANAGER 29/11/2013 10:47:23 AM 18772 (0x4954)
Failed to find properties of file 2 SMS_OFFLINE_SERVICING_MANAGER 29/11/2013 10:47:23 AM 18772 (0x4954)
____________________________________________________________________
Interesting thing was that the number “2” kept changing every time we tried to run the wizard for offline servicing.
On running the SQL query in SQl management Studio We got:
____________________________________________________________________
select distinct cpkg.Content_ID, ContentSubFolder, FileName from vCIAllContents cont join CI_ContentFiles cf on cf.Content_ID=cont.Content_ID join CI_ContentPackages cpkg on cpkg.Content_ID=cont.Content_ID join SMSPackages pkg on pkg.PkgID=cpkg.PkgID where CI_ID=16791696
____________________________________________________________________
Result:
Content ID ContentSubFolder Filename
16791021 2921051e-5897-4120-b749-0f38f3ea6ac9 windows6.1-kb982666-x64.cab
It turned out that the number “2” was the first character for the string “2921051e-5897-4120-b749-0f38f3ea6ac9”. This would change on subsequent attempts and the number “2” would be replaced by the first alphabet/digit of the value under ‘ContentSubFolder’.
This Number ‘2921051e-5897-4120-b749-0f38f3ea6ac9’ was actually the name of the folder in the ‘DataLib’ directory in ‘SMSContentLib’.
I:\SCCMContentLib\DataLib\2921051e-5897-4120-b749-0f38f3ea6ac9
Opening the INI file we got following value's inside it:
____________________________________________________________________
[File]
Attributes=00000020
Size=63945
TimeModified=129385629639903558
Hash=0DCA7A2935011E00ACE4B5C1E3A3AF51095B2FDC91449504265C3667934119DB
____________________________________________________________________
The FileLib Directory was split across multiple drives. We found that the actual content for this Update was stored on E:\.
E:\SCCMContentLib\FileLib\0DCA
For more information on how to navigate inside SCCMContentLib please refer to:
Thus we knew that the content was very much present, but, was not reachable from OfflineServicing thread. At this point I decided to use procmon for the entire process. I found out that the E:\ Directory was not even being scanned in this process:
Looking at the registry value 'HKLM\Software\Microsoft\SMS\DP\ContentLibUsableDrives' 'E:\' was not added over there.
On further investigation we found out that ‘NO_SMS_ON_DRIVE.SMS’ was present on ‘E:\’.This would make the smsexec process skip the drive when looking for content. We removed the ‘NO_SMS_ON_DRIVE.SMS’ from ‘E:\’ and restarted the ‘smsexec’ service. After this we got ‘E:\’ listed as a usable drive in registry:
We ran the wizard for Offline servicing again and this time it completed successfully.
Hope This Helps!
Shalabh Pradhan
Support Engineer | ConfigMgr Microsoft