surfincow

Found the following document: https://technet.microsoft.com/en-us/library/dn195881.aspx So reinstalled UAT, changed the registry clean up setting to 1, stop/start service so it would run the sync (and hopefully clean up) and it passed the prereq. Keeping fingers crossed

Hello, Trying to upgrade from 1702 to 1710 but received the following error during the pre-req check: Upgrade Assessment Toolkit is no longer supported. OK fine, not using it anyway so removed it from programs and features. Reboot, run the check again and it fails with the same error. Looking at the logs I see: INFO: Detected current installed build version [8498] for sitecode For Upgrade, an Upgrade Assessment Toolkit check is needed. INFO: Checking whether UAT table dbo.UAT_Application_Report or dbo.UAT_Device_Status has data INFO: Detected there is data in table dbo.UAT_Device_Status So it looks like there is some UAT data in the db. How can I fix this? There are no guides I can find on how to properly remove UAT and also how to purge any data to continue the upgrade. Server 2012R2/SQL2014 Thanks

Hello, I tried running the update KB but still things don't appear to be working. I installed the update, rebooted and things run at 90-100% for about 15 minutes then drops to about 5%. If I try to open the WSUS console, it can't connect so I think WSUS isnt running even though the service says it is. I had this problem last month and my fix at the time was to do the WSUS cleanup then block all hosts from connecting then gradually restore access one subnet at a time. I'm hesitant to do this again because the fix mentioned above from MS should resolve it, but in my case its not. Any thoughts?

Hello, I'm not aware of any way to have packages use custom icons. Applications have this ability because they are a new(ish) feature in SCCM added I think starting with the 2012 version. Its probably a feature request that could be added to allow this functionality but I'm guessing it was never added since the Application method is newer and what the majority of users would be using. Any reason not to use the Application method vs the Package method for those apps? For the missing icons, does it appear differently if you install say 7zip manually vs installed via SCCM? It could just be that the application does not have an icon that displays in Programs and Features and that's the reason for the generic icon. If no special icon appears when installing it manually then its something with the app itself rather than with SCCM. If it behaves different when its installed via SCCM then not sure what would cause that, but would be interested to find out if that's the case.

Just heard from MS that this bug will be fixed in the 1702 release which should be out by the end of the month.

Just a heads up if you've not installed this hotfix. Its causing some issues where Software Center fails to load. Issue appears to be the client stuck in provisioning mode and its a known bug with Microsoft. So far after talking to support there's no information on when this patch will be patched so beware More details: https://support.microsoft.com/en-us/help/4010155/update-rollup-for-system-center-configuration-manager-current-branch-v https://connect.microsoft.com/ConfigurationManagervnext/Feedback/Details/3127484 https://www.reddit.com/r/SCCM/comments/5wvcmr/update_rollup_for_1610_kb4010155/ https://social.technet.microsoft.com/Forums/en-US/c1665b4a-8ecb-4bdc-9ea6-a77f83413c38/sccm-1610-hotfix-kb4010155-has-a-serious-bug?forum=ConfigMgrCBGeneral

what is the low boot package?

Hello, After I upgraded ConfigMgr to 1610, I found none of my Windows 7 task sequences are able to complete. They fail at the "add driver" step and I believe it is due to the fact that the latest ADK 10.1.14393.0 is not backwards compatible with Windows 7. Since the ADK that is compatible with Windows 7 is not compatible with Windows 10 I had left the original working boot images for Windows 7 deployments and created a new boot image on the new ADK for Windows 10. Unfortunately during the upgrade configmgr re-generates the default boot images as part of the installation process. The default boot images were for Windows 7 machines. I've tried to re-import previous backups of boot images I have but get "• You can not import this boot image. Only finalized boot images are supported. For more information press F1." I've run across this with multiple boot images. Looking at others with the same issue this was a few years ago related to McAffee AV which we do not use. I created new boot images using the 1511 ADK and following these steps: # Create x64 Windows 10 ADK Boot Image mkdir D:\WINPEx64\Mount Copy "D:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us\winpe.wim" D:\WINPEx64\boot.wim dism.exe /mount-wim /wimfile:D:\WINPEx64\boot.wim /index:1 /mountdir:D:\WINPEx64\mount dism.exe /image:D:\WINPEx64\mount /add-package /packagepath:"D:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\winpe-wmi.cab" dism.exe /image:D:\WINPEx64\mount /add-package /packagepath:"D:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\winpe-scripting.cab" dism.exe /image:D:\WINPEx64\mount /add-package /packagepath:"D:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\winpe-wds-tools.cab" dism.exe /unmount-wim /mountdir:D:\WINPEx64\mount /commit and try to import and I get the same error. SMSprov.log reports: ERROR> Error -2146498530 returned to execute the command line: "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Image:"C:\Windows\TEMP\BootImages\{271040AD-B994-4EDC-9B5D-C6B286F87D15}\mount" /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-Scripting.cab" SMS Provider 2/4/2017 6:32:51 PM 9772 (0x262C) Failed to install required components into the boot image C:\Windows\TEMP\BootImages\{271040AD-B994-4EDC-9B5D-C6B286F87D15}\mount SMS Provider 2/4/2017 6:32:51 PM 9772 (0x262C) *~*~e:\cm1610_rtm\sms\siteserver\sdk_provider\smsprov\sspbootimagepackage.cpp(4054) : Failed to insert OSD binaries into the WIM file~*~* SMS Provider 2/4/2017 6:33:32 PM 9772 (0x262C) *~*~Failed to insert OSD binaries into the WIM file ~*~* SMS Provider 2/4/2017 6:33:32 PM 9772 (0x262C) Not quite sure where to go from here. I'm guessing it fails since its trying inject components from the current ADK into the image created with the older and running into a problem. Quite annoyed at the fact the latested ADK which needs to be installed to support the latest version of Windows 10 does not support the older versions of Windows. Makes for managing these types of issues a huge pain. Am curious how others are managing this? I've tried to find a list of folder paths to exclude for AV but can't find anything for the current version. At present I do exclude C:\Windows\Temp\BootImages and c:\ConfigMgr_OfflineImageServcing. Any clue how to get this working so I can import the older boot images? Thanks

Hello, We've deployed Office 365 to our users and I'm running into an issue when it comes to patching them with feature upgrades (security updates work just fine). O365 was originally deployed under current branch, but we've decided to go deferred instead. The GPO is set to use Deferred and also Office 365 client management is enabled. In the setup.xml file the parameter to update via configmgr was specified. The problem that I am seeing is that when the deferred channel updates are deployed, the machines don't detect or install them. When looking at the specific software update, none of the machines show "required" for the deferred updates, but rather for the "current" channel updates. I came across an article here: https://www.systemcenterdudes.com/managing-office-365-updates-with-sccm/that states the following: As per our testing, the GPO as no impact to change the Channel for Office 365 when managed by SCCM. When SCCM manage the updates, it will support only the Channel specified at the installation time. Example : You install Office 365 with Current Channel. You have a GPO setting Channel to Deferred. You deploy release updates with SCCM for Current and Deferred Channel, the client will only see the update for Current as necessary. Deferred will never be applied. This seems a little odd that you can only patch to what the update type is set to during installation. Has anyone else ran into this or are you able to change clients from one upgrade channel to another and still patch them through configmgr? Thanks

Hello, I've configured for our Windows 10 workstations (under client settings > Computer Restart set to 1440 (24 hours). The way I've always understood this to work is that anytime an Application / Package or Software Update required a restart that the user would have 24 hours after installation to do the reboot. Not sure if this has changed within the last few versions of ConfigMgr (currently 1606) but lately I've noticed the following. Packages behave the way I would expect. If I deploy a package and install it 5 hours before the deadline, I get 24 hours before the reboot is enforced. I also get 24 hours to restart if not installed before the deadline. Software Updates and Applications: If I install a software update or Application 5 hours before the deadline, I only get 5 hours before the restart is forced rather than 24 hours. If I let the deadline pass, the updates install and I get the 24 hour window. Something seems odd that with packages you always get a 24 hour window but Applications and SU you only get the 24 reboot window if you don't install the updates before the deadline. If you install them before the deadline then the machine restarts at the deadline rather than after 24 hours. For those who decide to install an update or application in a time period shorter than 24 hours before the deadline they sort of loose some of the extra flexibility of when to restart since they have effectively a shorter window. Is this the expected behavior?

When I originally inherited the SCCM responsibilities at my current job it was running 2007. When time came to move to 2012, I opted for a consultant to come help as I felt the original implementation wasn't done exactly the best (I don't blame the previous person though. I'm sure they set it up the best they knew at the time and learned as they went) and I figured moving to the new version I'd rather have it done right rather than deal with the consequences later. I believe he was here about a week helping to get the system setup. At that, its a system setup. Still lots and lots and LOTS to do. Re-creating / creating all the packages, switching them to applications when beneficial, getting updates working right and figuring out the deployment rules, etc etc etc. Probably took a few more weeks to get things at the point where I felt OK distributing the client and getting our workstations managed. Probably 6 months later I felt comfortable enough with it that we decided to move the patching of servers to sccm rather than WSUS. Fast forward a few years where I've been taking care of the thing and we need to upgrade to Current Branch. Since there was not a good upgrade path, I rebuilt everything from scratch. Since I'm a lot more familiar with it, learned a lot from the consultant and had a better idea of how I wanted to implement it I went ahead and did it on my own. Again, building out the systems and so forth easily took a week. Then working on the odd bugs (ah yes, this time I did decide to migrate packages and applications and ran into issues. Found out that's something that was never tested before the final version was released so there were problems....) Still after saving time by migrating data, it would be another few weeks before I felt things were good enough to move the clients over. At that point I was still hesitant about moving the servers over so it was another few weeks after the workstation migration that I moved the servers. There's just so much that can go wrong that I'd rather make sure everything works before rolling it out. I'm sure next time we need to re-deploy it I'll cut the time down even more but there's a huge difference between having the infrastructure built for SCCM and being able to do all the things SCCM lets you to do. The "making it work and do what you want it to" is the part that takes the longest time. Presently I'm in the same boat as you (different OS though). Need to deploy a system for managing Mac's and of course everyone wants it yesterday. The system we are going with compared to SCCM is dead simple amazing, but after working with SCCM for so long I'm used to how managing PC's works and getting used to a different way of doing it is difficult. For the SCCM part (and even my new project) the place I work at is pretty open if we need to call in external help for things. Don't know about where you work but if you are getting stuck and its delaying things, having someone come in who's gone through the setup numerous times might be a good idea. I have no idea about SCOM, but I know I would not have felt comfortable deploying SCCM the first time without any outside help. Fairly sure if I had it would have been a mess Good luck with your project. If it helps, I once saw it mentioned here that when quoting time frames for SCCM installs, if the SQL server is remote he always adds a week

Hello, In somewhat of an odd situation. We have a group of users who do some unique work and need to be able to modify any and all settings on their Windows 10 computer. Group Policy will allow us to set the correct security settings, however, this will prevent the users from being able to change them on their own if needed. Ideally it would be nice to handle this via group policy but I don't think that's going to work. I've checked around about methods to export GPO's and import them as local policies but the results don't seem to be that great. Other options we've considered is delegating GPO modification abilities to the users however as there are many, there would need to be many GPO's which would be quite silly. Also as they will work in environments where network may not be available, being able to VPN and make the needed changes isnt really possible. So I guess I'm wondering what if any idea's anyone has on how to do it. Thanks

Hello, To clarify, I am running ConfigMgr v1606 on Windows Server 2012R2. I've read the link previously but don't see anything stating the ADK isn't supported on 2012r2 (server). If its not supported on 2012R2 (server) then the only other option would be Windows 10, but I don't imagine anyone would be running Configmgr on Windows 10 or that its even supported or able to be installed. If there's something I missed in the link you provided stating the ADK does not work on 2012R2 (server), please provide direct link or copy/paste that specific info. Thanks

Ah, guess it worked. Description was just confusing

Hello, I am currently running the latest version of ConfigMgr (1606) on Windows 2012R2. We are starting to get ready to deploy Windows 10 1607 and I believe in order to do so, we need to update the ADK from 10.0.26624 to the ADK for Windows 10 1607 (image servicing, updated PE image, etc) When I look at the download link for the ADK (https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit) there is the following disclaimer: Note: You must use Windows 10, version 1607 with this version of the ADK. I'm somewhat confused by this as it implies (to me) it only runs on Windows 10 1607, but that can't be right since you would not run ConfigMgr on Windows 10. So I'm just wondering if this is the correct location for the ADK for Windows 2012R2? If yes, what does that note reference as it would then imply you can't deploy OS's other than 1607 with the boot images it creates. If not, has the ADK to support 1607 on 2012R2 been published yet? Thanks

Hi Sandy, Yes, we are using the in place upgrade for our current Windows 7 and Windows 10 machines, this would be for brand new machines. ConfigMangler - Reason to upgrade the OS during OSD is there is quite a bit of customization done in the base OS that's already in use. Enough that to go through and build a new image for deployment versus spend time working on the 1607 image does not make sense. If I could quickly upgrade the OS during deployment that would be handy as it would require little to no work and allow me to direct resources towards 1607.

Hello, We are still deploying the original Windows 10 for OSD. We've started upgrading our existing workstations to 1511 via Software Update and I'm working on building the new image for 1607. Its probably going to be a few more weeks until that is ready and at present our service desk after deploying a machine needs to run the upgrade to 1511. This isn't ideal as it takes manual work that we want to avoid. I tried adding the "Upgrade Operating System" task sequence step to the existing task sequence but that does not appear to work. Looking for the 1511 update in the list of updates to patch the image offline isnt there either. Is there any way to automatically upgrade the OS to 1511 during OSD or offline so it does not need to be done post-deployment? Thanks

posted in wrong forum, please delete

You can try deploying the task sequence as "available" then a second as "required" with a deadline a year in the future (and not visible in software center). If that works the same way as with packages then content would be downloaded (due to the required deployment) but then be used when the "available" deployment is run. (you might need to use 2 separate collections if it won't let you deploy the same TS to a collection that its already advertised to) I've not used TS's outside normal OSD that often so not terribly familiar with how it works with an existing OS. I'm fairly certain my suggestion won't work, but its one thought and should be fairly quick/simple to test. If this does work keep in mind you may use up all the client cache for this TS and it could cause problems with future deployments if there's not space available for it to download. And also don't forget at some point to remove the required deployment otherwise bad things might happen. Maybe could make the required task sequence the same as the available TS but add another step right at the beginning that would cause it to fail so if for some reason you forget to remove it or it gets run by accident nothing bad happens.

Hello, I'm not sure if that gets logged anywhere but I suppose you can compare 2 machines of the same model. Install one without specifying a driver package and then one with. You should see a difference (hopefully) on the one without driver packages having missing devices.

Hello, The way it was done in the link you provided was doing drivers with download package content. You'd do a different package content for each model device you have and make that run only if your wmi query for that hardware matches. In the example they only did one, but if you had more, you'd just add with the appropriate drivers and wmi query. Then when the upgrade operating system step runs afterwards, it looks for the drivers that were downloaded from the earlier download package content steps and applies them. That's one way to do it, but the way I did it was rather than have multiple download package content steps and deal with variables and paths (that some people had issues with), I just skipped the download content package parts and made multiple upgrade operating steps. One for each model and selected driver package instead of staged content and then added a WMI filter to the step. Either methods should achieve the same result but the way I went with made more sense to me and seem more strait forward. The method posted as I said also works and also shows off a new feature in task sequences so its good to get familiar with that anyway.

I see though you have option 66 and 67 in the screenshots. I don't believe you need those and if they are still present could be causing a problem. I had some issues where the PXE server response delay (Distribution Point Properties > PXE Tab) was set to the wrong value. I have mine set now to 5 and it works, but before it was either too low (0) or too high (30). Can't remember which but you might try changing yours from 0 to 5 and see if anything changes. Also doing an "update distribution point" for your bootimages tends to fix odd issues when PXE stops working.

Hello, I don't believe you need any DHCP options configured if you are using IP-Helpers to direct the DHCP and PXE boot requests. I think the bootfile name is where you are having the problem since they are different for UEFI and BIOS (if I recall correctly). If you take everything out of DHCP in regards to PXE and let the IP Helpers do their thing, the DHCP server will reply back with what it knows and the ConfigMgr/WDS/PXE will respond back with what it knows about its services. Then things should work. I referenced this when we moved from BIOS to BIOS and UEFI and had similar issues https://technet.microsoft.com/en-us/library/Cc732351%28v=WS.10%29.aspx#Updating

Hello, Getting ready to roll out our Windows 7 to Windows 10 upgrade task sequence which has been working great during our testing. However, since the recent upgrade to 1606, users in the pilot are getting the following message when they try to launch the upgrade via Software Center: Looking at the logs, I found this SCClient log: <![LOG[Call to ExecuteMethod failed, WMI MethodName "CCM_ProgramsManager", MethodClass "ExecuteProgram", called by (Microsoft.SoftwareCenter.Client.Data.WmiConnectionManager at ExecuteMethod)]LOG]!><time="12:40:50.8041475" date="8-31-2016" component="SCClient" context="" type="3" thread="7" file=""> <![LOG[Exception caught in ExecuteMethod, line 383, file C:\vso\_work\9\s\DataAbstractionLib\WmiDataProvider\WmiConnectionManager.cs - Type System.Management.ManagementException: Not found (Microsoft.SoftwareCenter.Client.Data.WmiConnectionManager at ExecuteMethod)]LOG]!><time="12:40:50.8071598" date="8-31-2016" component="SCClient" context="" type="3" thread="7" file=""> <![LOG[stackTrace: at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode) at System.Management.ManagementObject.InvokeMethod(String methodName, ManagementBaseObject inParameters, InvokeMethodOptions options) at Microsoft.SoftwareCenter.Client.Data.WmiConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, String callerMethodName)]LOG]!><time="12:40:50.8161967" date="8-31-2016" component="SCClient" context="" type="3" thread="7" file=""> <![LOG[unhandled exception was caught. (Microsoft.SoftwareCenter.Client.SingleInstanceApplication at OnGetException)]LOG]!><time="12:40:50.8212172" date="8-31-2016" component="SCClient" context="" type="3" thread="1" file=""> <![LOG[Exception caught in OnGetException, line 170, file C:\vso\_work\9\s\SoftwareCenterApplication\App.cs - Type Microsoft.SoftwareCenter.Client.Data.WmiException: Not found (Microsoft.SoftwareCenter.Client.SingleInstanceApplication at OnGetException)]LOG]!><time="12:40:50.8222213" date="8-31-2016" component="SCClient" context="" type="3" thread="1" file=""> <![LOG[stackTrace: at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode) at System.Management.ManagementObject.InvokeMethod(String methodName, ManagementBaseObject inParameters, InvokeMethodOptions options) at Microsoft.SoftwareCenter.Client.Data.WmiConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, String callerMethodName)]LOG]!><time="12:40:50.8222213" date="8-31-2016" component="SCClient" context="" type="3" thread="1" file=""> During the testing pre-1606 upgrade, I personally tested it on multuple VM's and on several different models of notebooks and never received the error. Now though, I've been able to replicate the error a few times and not sure what would be causing it as Software Center appears to be working fine. You can see the different apps/updates/operating system deployments, install applications but when you try the task sequence, it will give the warning about it being an operating system upgrade and that you will lose your data (normal warning) then it gives this message. I've been able to move past this on my test machines by waiting a few minutes and trying again, or when that didn't work running ccmreset.exe. The other testers though arent having much luck so I'm hoping someone here may know what the issue might be. I do notice it references: C:\vso which there is no such directory. CM 1606 on 2012R2 with the 5.00.8412.1007 client on Windows 7 SP1 computers. Thanks

Ah OK, now I see part of the problem. It drops all the driver packages into the Root folder while I was expecting them to be sorted similar to how they are in the driver packages section in the console. Now that I see you can actually select the driver packages in that step. Makes more sense now