crossan007

Hello! I've got a strange issue with Internet Based Client Management where clients are not communicating when outside of the network. Some interesting things I've found in client side logs: LocationServices.log: 1 internet MP errors in the last 10 minutes, threshold is 5. In CCMMessaging.log, I'm seeing a few of these: Post to https://----sccm-01.-------------.org/ccm_system/request failed with 0x87d00231. Interesting Server Side Logs: ClientAuth.log: Error verifying message from client 'GUID:736B0572-FF7D-45BD-84D2-5E5C6C6F6EC8' (0x80090006). Message from GUID:abb9de52-52f6-42fa-8901-9e65513e5faf client failed signature validation Skipping raising MPEvent_ClientAuth_SignatureFailure event because 4 such events were already raised in the past 60 minutes Could not verify message signature for client 'GUID:abb9de52-52f6-42fa-8901-9e65513e5faf'. ClientLocation.log Raising pending event: instance of CCM_LocationServices_LocationBaseChange { ClientID = "GUID:abb9de52-52f6-42fa-8901-9e65513e5faf"; DateTime = "20160610201145.755000+000"; NewLocation = "Internet"; OldLocation = "Intranet"; ProcessID = 3264; ThreadID = 1464; }; Unable to retrieve AD forest + domain membership. Error 0x8007054b Some background on the environment: Single server with all roles and SQL (~6,000 clients), 32 GB ram, 24 cores. All clients are well connected - no slow links.Upgraded existing server from SCCM 2012 R2 CU5 to SCCM 1511, then to 1602, then did a backup/restore onto new hardware to get the server from 2008 R2 to 2012 R2 Two domains, both have Discovery Methods set up in SCCM, and clients are working internally Newly configured three-tier CA: Offline root Standalone CA, one subordinate issuing Enterprise CACRL and AIA is published over HTTP. Both CRL and AIA are internet accessible. Group Policy for Trusted Root certificate, and client auto enrollment are both configured. All clients in both domains have the Offline Root Cert in the Computer Accounts Trusted Root store. All clients in both domains are being issued SCCM Client authentication Certs from the CA SCCM Server's DP cert is installed, SCCM DNS is published internally and externally with the same name. NATs and ACLs are working on the firewall, and the mplist test methods do return valid XML internally and externally Where else should I look to troubleshoot / diagnose? It almost seems like something with the CA / certs installed, but I *think* they're correct... Has anyone else had similar issues with IBCM, and how did you fix it? Any help / guidance would be appreciated! Thanks!

Not yet. I haven't actually tried to reproduce the issue in a clean environment - this was discovered "in the wild" while migrating a customer's environment I'll try to reproduce the bug in a sandbox to see if it's consistent.

Cross Post from https://www.ccrossan.com/sccm/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: A driver is added to SCCM A category is assigned to the driver The category is deleted from the driver 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: Fire Up SQL Server Management Studio Create a New Query, and select your Site Database For each failing driver entry (as seen in “C:\Program Files\Microsoft Configuration Manager\Logs\migmctrl.log”), Run the following SQL Query: SELECT * FROM CI_CategoryInstances WHERE CategoryInstance_UniqueID LIKE '%c6e9d9e3-1371-46ba-b7f1-bb46c5b6bc06%' Note the CategoryInstanceID (should be like 16777601) 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 $_ } Repeat the above section for each unique CategoryInstance_UniqueID listed in the “C:\Program Files\Microsoft Configuration Manager\Logs\migmctrl.log” file. When complete, retry the migration, and examine for any additional missing CategoryInstance_UniqueID errors.

I recently wanted to wake a group of computer, and was trying to figure out how to do it from the SCCM console. One method I found was to create a "dummy package" and deploy it with the "send wol packets" box checked off. I didn't like this option, so I did some scouting. I found the wonderful "SCCM Client Actions Tool" which is found at: http://sccmcat.codep...ases/view/85803 While this tool is great, it still didn't do everything I wanted (namely Config Manger console integration). Also, I noticed that subnet directed broadcasts were not working (though my network is configured for them.) Upon deeper inspection, I realized that the WOL.exe included with the application did not support the feature. I decided to replace it (and update the HTA app) with the Depicus WOL Tool (found at http://www.depicus.c...on-lan-cmd.aspx). I opened up the HTA application (plain old HTML / VBS / CSS) and made some changes. I added a handler to process command line arguments (just one argument actually - WOL in this case, though more may come), and then I made a console Action Extension xml file to integrate into the Device Collections node. My Device Collection ribbon bar now has a new button: If you'd like the files I built for this, send me a PM with your email address and I'll send them to you (since I'm not allowed to upload HTAs to this forum). I make no guarantees that it will work for you as intended, but if you find a bug and let me know, I may eventually look into it. The HTA source code is open so I encourage you to examine it and make sure it won't do anything bad to your network before you use it (I'm not responsible for any possible damages caused by it)

I was having a different problem (which i unfortunately did not document as well) in which a few errors would prevent the deployment from succeeding. The task sequence failed when it began downloading the OS. I attempted to remove / re install WDS (and associated files - namely the boot.wim) from the server, and in this process I wound up with new boot.wim files from a Windows 7 Enterprise ISO. While this was probably not the best move, I figured I'd share what I found in case anyone else was encountering something similar. In hindsight, a re-install of SCCM (or simply restoring a backup of the original WIM files had I actually made them -- snapshots are our friends) would probably have been a more efficient option...

I'm not sure if this was the most elegant fix, so if anyone has some input on why I had to do all this, please comment! Thank you

I Set up SCCM 2012 RTM, and have been fighting with deploy and capture for a few days. I successfully imported an Operating System Installer I successfully created a task sequence I I was able to get the machine to PXE boot, and it almost loaded windows PE; however, I kept getting the following error message: Windows PE cannot start because the actual SYSTEM ROOT directory (x:\windows) is differrent from the configured one (x:\$windows.~bt\windows). This can be configured from dism.exe with the /set-target path command. please refer the documentation for more details I was able to trace this problem back to using a boot.wim file other than the one included with SCCM / WDS. I had deleted the original boot.wim files, and used one from a windows 7 install cd. To resolve the problem, i used dsim.exe to modify the boot image: C:\sources\os >mkdir wim C:\sources\os>dism /mount-wim /wimfile:boot86.AAA0001c.WIM /index:1 /mountdir:wim C:\sources\os>dism /image:wim /set-targetpath:X:\ Deployment Image Servicing and Management tool Version: 6.1.7600.16385 Image Version: 6.1.7600.16385 Target Path : X:\ The operation completed successfully. C:\sources\os>dism /unmount-wim /mountdir:wim /commit Deployment Image Servicing and Management tool Version: 6.1.7600.16385 Image File : C:\sources\os\boot64.AAA0001b.WIM Image Index : 1 Saving image [==========================100.0%==========================] Unmounting image [==========================100.0%==========================] The operation completed successfully. C:\sources\os>copy boot86.AAA0001C.WIM c:\RemoteInstall\SMSImages\AAA0001C\ Overwrite c:\RemoteInstall\SMSImages\AAA0001C\boot86.AAA0001C.WIM? (Yes/No/All): y 1 file(s) copied. After these commands, I was able to boot into launching the Task Sequence to Build and Capture my windows 7 image (Don't mind the x86/x64 difference from the screenshot and the commands above, I had to do the procedure twice...once for each boot image) However, after the Build and Capture, I was again presented with the same error I rebooted into the PXE WinPE (F12 network boot), and launched command prompt (F8 if you have enabled it within the SCCM image): I repeated the same procedure as I did on the PXE boot image for the local image, but first i had to find out where the local image was: X:\sms\bin\i386 >bcdedit Windows Boot Manager -------------------- identifier {bootmgr} description Windows Boot Manager locale en-US inherit {globalsettings} default {default} displayorder {default} timeout 30 Windows Setup ------------- identifier {default} device ramdisk=[C:]\_SMSTaskSequence\WinPE\sources\boot.wim,{ra mdiskoptions} path \windows\system32\boot\winload.exe description Windows Setup locale en-US inherit {bootloadersettings} osdevice ramdisk=[C:]\_SMSTaskSequence\WinPE\sources\boot.wim,{ra mdiskoptions} systemroot \windows nx OptOut detecthal Yes winpe Yes My local (hard-disk) image is in =[C:]\_SMSTaskSequence\WinPE\sources\boot.wim, So I ran the same commands against that file: C:\_SMSTaskSequence\WinPE >mkdir wim C:\_SMSTaskSequence\WinPE\sources>dism /mount-wim /wimfile:boot.wim /index:1 /mountdir:wim Deployment Image Servicing and Management tool Version: 6.1.7601.17514 Mounting image [==========================100.0%==========================] The operation completed successfully. C:\_SMSTaskSequence\WinPE\sources>dism /image:wim /set-targetpath:X:\ Deployment Image Servicing and Management tool Version: 6.1.7601.17514 Image Version: 6.1.7601.17514 Target Path : X:\ The operation completed successfully. C:\_SMSTaskSequence\WinPE\sources>dism /unmount-wim /mountdir:wim /commit Deployment Image Servicing and Management tool Version: 6.1.7601.17514 Image File : C:\_SMSTaskSequence\WinPE\sources\boot.wim Image Index : 1 Saving image [==========================100.0%==========================] Unmounting image [==========================100.0%==========================] The operation completed successfully. Then I rebooted and everything continued along happily