Search the Community

Hi everyone. I'm hoping someone out there can assist. Sorry for the length post but my aim is to provide as much information as possible to eliminate any of the common gotchas. ConfigMgr is 1702 with latest Hotfix I've spent the better part of two weeks trying to figure out why OSD has all of a suddenly stopped working. It seems to have happened around the same we upgraded our last DC from server 2012 to 2016 (swing migration) and raised the domain fictional level from 2012 to 2016. From the many hours spent doing google kung fu, ConfigMrg should not have any issues working in 2016 etc. DNS, DHCP AD are all reporting healthy with the usual couple of things that we can ignore from the BPA (Best Practices Analyzer). How we do OSD: We exclusively image Unknown Computers and have done so for many years (Since 2012 R2). We do not image our machines using deployments to any other collection. We delete the computer from the SCCM DB when we need to re-image. This works well for us in our environment. :-) All Task Sequences are deployed to the Unknown Computer collection. We are using ADK 1703 (the most recent one with all bug fixes) and boot boot x86 and x64 boot images are distributed and enabled but we only use the x64 boot image. The issue: Machines can successfully PXE Boot into WinPE, all machines no matter make, model, physical or virtual) all get an IP address and we can ping the ConfigMrg server without any issues. Once a computer gets into WinPE the screen goes blank and the computer reboots straight away. Actions taken so far: Common gotchas I have checked: Checked the date and time are correct on the client Made sure to delete any unknown computers or any references to the machines I have been using for testing or imaging in general Thinking that it might possibly be a Boot Image/PXE related issue I followed a couple of very detailed guides online and removed the PXE role from the Distributions Points by: Unticking it from each DP, deleting the files in the Windows Temp folder, deleting the RemoteInstall folder, removing the Boot images from DP's, the usual reboots, checking logs, re-enabling the PXE roll on DP's rebuilding the Boot images, deploying the boot images, enabling the both x86 and x64 boot images, making sure that my Task Sequences were referencing the newly created boot images. I then booted a machine up (in this case a test VM) and pressed F8, I ran cmtrace and opened up X:Windows\Temp\SMSTSLog\smsts.log. Then I found this error message: There are no task sequences available to this computer.. Please ensure you have at least one task sequence advertised to this computer. Unspecified error (Error: 80004005; Source: Windows) TSPxe 12/07/2017 12:28:40 PM 1284 (0x0504) So I thought perhaps my Task Sequence deployments themselves might have some issue on the DP's. I tried redeploying the task sequences and creating a brad new Task Sequence to test and I still got the same error. I checked the boundary groups and Active Directory Sites and Services and everything looks fine. I tried initiating a discovery of everything possible. Here is an example screen capture video of the issue we are experiencing: Looking forward to any comments below!

Hi all, I've headed here to post my problem as I've spent the best part of 2 weeks on and off troubleshooting and I'm not getting anywhere. The company I'm currently working for now have a mixture of Windows 10 clients in their environment. 1511, 1607, 1703, 1709. We've been plugging away for months now to try and clear the last few hundred 1511 clients as we suffered from the WSUS decryption key issue with Feature Updates, but this was resolved and seemed to be working fine. We don't use servicing plans at all as we prefer to control the deployments more manually via direct deployments of the Feature Updates to device collections. We're now down to just over 100 1511 clients and we've been upgrading them to 1703 until we've unearthed a new problem. Around 75 of the machines in the collection are not receiving the Feature Update in Software Center. After a bit of digging it became clear that these machines think they are already "compliant" when reviewing the SCCM deployment under the monitoring pane! We have now seen this same behaviour when trying to advertise the 1703 Feature Update to some 1607 clients. I've read about the "defer upgrades" GPO causing problems and as a result I have a new GPO to turn these settings off and prevent the client from trying to use WUfB (Windows Update for Business) but these machines still remain "compliant". On Friday I built a VM with our Corporate 1607 build to use as a test machine. This VM is showing compliant when I deploy the 1703 Feature Update to it so I tried the 1709 Update and this has appeared in software Center. It seems to be a bit random as to which machines report as compliant and which don't. Some have "defer updates" set, some don't, there doesn't appear to be an obvious pattern. Has 1703 recently been written off because Microsoft prefer clients to be on the most latest version as soon as it is classed as being Business Ready??? Please let me know if anyone has any ideas or suggestions to troubleshoot this as I'd like to straighten it out before we need to start upgrading the remaining 1607 clients. Thanks in advance, Westy

Hi all, I'm hoping that someone can help as I'm really struggling to find anyone else that's had this specific problem. When trying to build brand new HP equipment with an SCCM (MDT integrated) OSD task sequence I am seeing the following error when the machine runs the "Invoke-MbamClientDeployment.ps1" script: Failed to escrow TPM owner-auth to http://MBAMSERVER.domain/MBAMRecoveryAndHardwareService/CoreService.svc. HRESULT: 0x80280012 I've found that 0x80280012 means "There is no Storage Root Key (SRK) set." but I'm struggling to understand why this error only effects some new machines and not others even though they are all the same model and spec. We have a workaround which seems to be working every single time which is to turn on a new machine and let it run through OOBE of the shipped W10 OS then once completed, reboot the machine and PXE boot to the W10 Task Sequence. So something during the OOBE of a brand new machine seems to be creating/setting the SRK for the very first time. Does anyone have any ideas as to what might be causing this and how/when a TPM SRK is initially created? Thanks in advance, Westy

Hi Everybody, We are working on a new image with Windows 10 1703 en-US, but now we have a customer who wants the nl-NL languagepack to be installed. What I have done: - Created an unattended.xml with settings <InputLocale>0413:00020409</InputLocale> <SystemLocale>nl-NL</SystemLocale> <UILanguage>nl-NL</UILanguage> <UserLocale>nl-NL</UserLocale> <UILanguageFallback>en-US</UILanguageFallback> - Created a package for the languagepack - Created a MDT task sequence step to install the offline languagepack Started the deployment, languagepack seems to be installed alright, but when the machine boots up, only the date/time are in Dutch. So the display-language is still in English. After that I installed the Dutch languagepack via lpksetup.exe, rebooted the machine and now everything is in Dutch. It seems that Windows 10 is trying to contact Windows Update to search for the display language packages, but Windows Update is blocked, because everything is going via SCCM. Any advice is very welcome on how to install this on the right way.

Hi there. I've followed the excellent guide on this site (thanks Niall!) for integrating Language Interface Packs into a Task Sequence and it seems to work pretty well for me. Something i thought of though, let's say for arguments sake that i rollout Win 10 1607 with a bunch of LIP's in a Task Sequence and further down the line i have a number of different computers with different LIP's installed. I now want to upgrade these machines to Windows 10 1703. Given that there are different LIP's for each build of Windows 10 I'd suspect that i would need to also upgrade the LIP on any machine where a 1607 LIP is installed. Is that a correct assumption? Assuming that it is, i was wondering how do i programatically identify machines that have, say, a Japanese LIP installed, so that when their OS is upgraded to 1703 that the Japanese 1703 LIP also gets installed? Anyone tackled this scenario before? Thanks

Introduction Microsoft have yet again released a new update, this time it's System Center Configuration Manager 1703 (Technical Preview). This is a quick post to highlight a detailed video I've just created and uploaded to youtube. The video shows the entire process from start to finish including Initiating the Upgrade Using CMTrace to review log files Checking status in the console Which logfiles to review Where the content is downloaded Determining the package GUID Upgrading the console Tips advice and more. Please take a look and tell me what you think.

So it seems that Microsoft Deprecated some. My image was working fine and skipping those pages, but for whatever reason, it stopped skipping them. "SkipMachineOOBE" is deprecated in the Windows image "SkipUserOOBE" is deprecated in the Windows image What is the method to eliminate the pages from showing up when my TS completes so that I don't have to choose the timezone, etc. ??

I have started testing PXE image deployment of Win10v1703x64. Now that I have fixed my boot images (it upgraded them, but all my OS images were still pointing to the old ones), it deploys successfully. However, I do have one quirk. After the 2nd reboot where it would start to "Setup Operating System" and configure the client, I only see a blue screen that says "Just a moment". Some other forums also have people with this problem. The tasks appear to continue in the background, but I cannot see the progress of image deployment/setup. Any guidance?

I just upgraded to 1703 using a Servicing Plan in SCCM, however I lost all the pinned program from the Start menu. Also, I had to re-install the RSAT update. Wondering if you anyone had the same issue? Thanks,

I've got an instance of ConfigMgr 1703 running to replace our old 2012R2 site, and we have six offices in other locations we need secondary sites for so we don't have a lot of MP and DP traffic across the WAN. I successfully provisioned the first secondary site this morning, but now I am trying to set the Client Push installation settings and when attempting to specify the service account, I get the attached error message. Once this pops up it crashes my ConfigMgr console, and it happens on my local workstation, my primary site server or the remote MP. Any ideas where to start troubleshooting this issue? I used the same account on the Primary site server for client push installation and it worked fine. Push works within the local site, but obviously fails at the remote site.