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