Jump to content


Established Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Westy182 last won the day on May 4 2018

Westy182 had the most liked content!

Community Reputation

2 Neutral

About Westy182

  • Rank

Recent Profile Visitors

1,054 profile views
  1. Hi all, I hope someone can help me, even if it's just to say this isn't possible.... We currently have an SCCM 1806 environment with HTTPS/PKI enabled. All domain joined machines receive their personal PKI cert to allow SCCM client communication via GPO and this works fine. We have a need to build servers that are in a DMZ workgroup and at present these are built using a standard OSD task sequence which joins them to the domain. The server then has to be manually removed from the domain and added to the DMZ workgroup, then a certificate needs to be requested from the Certificate Authority and applied to the server. I'm in the process of trying to streamline all server builds, and this is one area that has come up where the company would like to reduce manual task if possible. When joining a workgroup during an OSD task sequence things obviously stop working once the SCCM client is installed as the communication to an MP doesn't occur. Is there a way to build a machine using a Task Sequence where it can be added to a workgroup and continue to communicate to the MP and finish the TS? I have been playing around with some scripts to request a PKI cert so that in can be applied in the TS prior to the SCCM client being installed but I'm really struggling now and don't even know whether what I'm trying to do is even possible at all! I've been unable to find a guide to doing this some I'm wondering if it's impossible. Has anyone got any pointers? Thanks in advance. Westy
  2. I think the following blog answers my question as to what's happening with the Recovery partition during an OSD via SCCM: https://miketerrill.net/2017/07/12/configuration-manager-osd-recovery-partitions-and-mbr2gpt/ "Behind the scenes, it creates a diskpart answer file that it uses to partition and format the disk. The Recovery partition is getting set to type 7 instead of type 27 (hidden). When the Windows 10 Setup runs, it does not recognize (or use) the Recovery partition that was created by Configuration Manager" It doesn't clarify whether this is a bug in SCCM or whether anything has been done to remedy the disk part step but I have found a solution that I've successfully tested this morning: https://garytown.com/osd-partition-setup-mike-terrill-edition-the-optimized-way I now have a daunting task of trying to clean up the existing environment. Deleting any tiny Recovery partitions that were created as Primary parts, and creating proper usable 984 mb Recovery partitions.
  3. Hi all, I hope you can help as I've been search for some clarity on this matter for the last 2 days. Sorry for this, it's going to be a long one..... I'm working for a company who finished migrating to Windows 10 (1703 & 1709) last year. There are around 10k Windows 10 devices which are predominately legacy BIOS configured and now need to be converted to UEFI using the MBR2GPT tool. The devices were built using an SCCM task sequence (SCCM 1802) with MDT 2013 Update 1 integrated. I've just started to do some testing with the MBR2GPT tool using the guide linked below and have found the following issue(s) in this environment. I'll highlight these issues then explain the main problem/bug I seem to have: Guide: https://miketerrill.net/2017/09/06/windows-10-bios-to-uefi-in-place-upgrade-task-sequence-using-mbr2gpt/ - First problem is as discussed in the questions section of the above blog. The step that re-enables the Recovery Environment is failing as the only available disk partition that can be used is Bitlocker encrypted. - The second issue is that most of the machines in the estate have 128 GB hard disks and the recovery environment partition is being created at 12 mb in size which renders it useless. So I took a look at what is going on in our task sequence and found the following disk partition steps for a BIOS system: System Reserved (Primary) 350 MB fixed size. NTFS file system. Windows (Primary) 99% of remaining space on disk. NTFS file system. Recovery (Recovery) 1% of remaining space on disk. NTFS file system. This was obviously the issue as after the first 2 partitions had been created, 1% of the remaining space equated to 12mb. This problem led me to find the following blog which explains that either the SCCM or MDT task sequence template had been wrong at some stage in 2015: https://blogs.technet.microsoft.com/jchalfant/configuration-manager-2012-sp2-r2-sp1-incorrectly-sizes-partitions-during-formatting-steps/ Apart from the problem where I can't re-enable the RE after the BIOS to UEFI switch I also noticed that the 12 mb partition had been given a drive letter in the OS! This appears to be normal behaviour for any Primary partitions following the MBR2GPT conversion, however, this should be a "Recovery" partition right?! So I've spent the last 2 days building machines with different disk partition steps to try and pin down what's going on. The first think that sticks out like a sore thumb is that when you create a standard SCCM TS the disk part steps completely contradict those in the MDT TS template. I asked a former colleague who has a later version of MDT integration in his environment to send me the disk part config and again it's different. It appears that the "Recovery" partition, even when created large enough to work, is not actually being created as a hidden recovery partition but instead as a "Primary" partition. This explains 1, why I can't re-enable the RE agent, and 2, why a drive letter is being mapped to this partition after the MBR2GPT conversion. To add to the fun, we have run Win 10 Feature Updates across almost 2500 machines and this appears to have created a useable recovery partition (a proper one with "Type" "Recovery") as part of the upgrade. Unfortunately this then means that there are 4 partitions on the MBR disk and the MBR2GPT tool is unable to create the EFI partition if there are more than 3 MBR partitions. My testing has led me to believe that I can safely run MBR2GPT tool to convert these machines once I've scripted a cleanup of the tiny un-useable partition. Let me know if anyone else has had similar woes with this. But basically my questions are this: 1) Can someone please clarify what the actual BIOS and UEFI disk partition steps should be in a Bare Metal Task Sequence? 2) Why isn't an MBR Recovery partition showing up in diskpart or disk management as a recovery partition? Thanks in advance. Hope it makes sense, and sorry for the essay. Westy
  4. Thanks for you reply. I think we're going to be logging a ticket to Microsoft for this problem now. I've tried manually deleting things from the content library to try and trick a full redistribution but I think the record may need deleting from the database which I don't really want to do without knowing exactly what I need to delete. I found the following query that can be run on the DB to detect the status of a package: Select * FROM PkgServers WHERE PkgID = 'ABC00123' AND NALPath Like '%MYSERVERNAME01%' You can set the "RefreshTrigger", "UpdateMask", and "Action" tables to trigger a redistribution using this command: UPDATE PkgServers SET RefreshTrigger = 1, UpdateMask = 4, Action = 1 WHERE PkgID = 'ABC00123' AND NALPath Like '%MYSERVERNAME01%' But this is the same as doing a redistribution from the SCCM console or the content library. I found that when a brand new package is first sent to a DP is uses "RefreshTrigger = 0", "UpdateMask = 0", and "Action = 2". so I tried setting this on my faulty package but it just will not re-send the files. You can see the package being referenced in the distmgr.log but it doesn't push any files as the DB shows that they already exist on that site.
  5. Hi all, A problem that seems to be occurring more and more frequently in the environment I'm currently working in is content not successfully distributing to Distribution Points. We have over 130 secondary site servers in the environment and it's common to find "Invalid" content when using the Content Library Explorer tool. If a piece of content is "Invalid" I normally can't successfully remove it via the SCCM console as it then goes into a orphaned state in the content library. If left for any period of time and then re-distributed to the problem DP, the files never go through the despool.box yet the distribution status pie chart will show green and the content library explorer changes back to "Invalid". If I try to "re-distribute" the content from the SCCM console it just evaluates to already be there and stays in an "Invalid" state. Sometimes updating the content version number and redistributing can fix the issue but 9 times out of 10 it just changes the version number in the content library but the content remains "Invalid" I've been scouring the net trying to find a WMI/Powershell cmd to trigger a full resync of content for a specific package but I can't find anything. Is there a way to do this either via WMI, Powershell, or directly in the SQL DB? Even if the best solution is to delete the files directly from the content library I just need to find a reliable way to fully re-sync "Invalid" content. We're using SCCM 1802 but this isn't a new problem, it's been knocking around for a long time. I hope someone has a script or a trick that can help me sort this issue. Thanks in advance, Westy
  6. Apologies as I was rushing when I posted that snippet above. Open the "MigUser.xml" which is a standard file with USMT. Search for "This component migrates user files with known extension" and then add the following line into this section: <script>MigXmlHelper.GenerateDrivePatterns ("* [*.snt]", "Fixed")</script> This should then migrate any W7 .snt files from APPDATA/Roaming/MICROSOFT/Sticky notes to the same place on a W10 machine. Then the first time you launch Windows 10 Sticky Notes it will check this location for any legacy .snt files for that user profile and migrate it into the W10 area AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe Hope this helps, Westy
  7. <!-- This component migrates user files with known extension--> <component type="Documents" context="UserAndSystem"> <displayName _locID="miguser.userdata">User Data</displayName> <role role="Data"> <rules context="System"> <include> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.snt]", "Fixed")</script> </objectSet>
  8. I found that if you confirm that your USMT scripts have a migration rule for the .snt extension and you let it migrate from a W7 machine to the same location on a W10 machine, the W10 modern app will check the old W7 location and auto migrate any .snt files to the new area on first run.
  9. Found the infor relating to this issue from Microsoft too: https://support.microsoft.com/en-us/help/4093120 Known issues in this update Symptom Workaround After you install the March 13, 2018 or later Cumulative Update for Windows 10 Version 1607, only the latest Windows 10 feature update is returned as applicable. This prevents the deployment of previously released feature updates using ConfigMgr (current branch) and Windows 10 servicing plans. Decline all feature updates on the WSUS servers except for the one that you want to deploy by using ConfigMgr. Run another software update scan cycle from the ConfigMgr control panel (or wait until the client devices run their next scan). Microsoft is working on a resolution and will provide an update in an upcoming release.
  10. Just to confirm, I've removed "2018-04 Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4093119)" and now the 1703 Feature Update has appeared in Software Center! I'll get the CUs for each month of this year and try to find out where it's breaking.
  11. Hi Niall, That is a good shout as we did have issues with Feature Updates at the end of last year on machines with old SCCM clients. Updating those clients did indeed fix them. We're now on SCCM 1710 and client version 5.00.8577.1108. I've actually just found some info online where someone else with a similar issue found that some of the recent 2018 Cumulative/Security updates have caused clients to now report in as being compliant. I'm removing the 2018-04 patches I have installed and testing again.
  12. 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
  13. 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
  14. Hi all, I really hope someone can help as I've spent an unbelievable amount of time trying to get this working with no success. I'm using USMT from the 1607 ADK and I'm trying to relocate a legacy Sticky Note file (.snt) from a windows 7 machine to the new Sticky Note modern app location on a Windows 10 machine. W7 location = %AppData%\Roaming\Sticky Notes\StickyNotes.snt W10 (1607) location = %LocalAppData%\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState My USMT script is currently able to sucessfully collect up the snt file from a W7 machine and return it to the exact same place on a W10 machine but a manual step is then required to move this file to the new loaction. A legacy snt file can be migrated to W10 by creating a new folder called "Legacy" and putting the "StickyNotes.snt" file in there and renaming it to "ThresholdNotes.snt". So I require the USMT restore to create the "Legacy" folder, put the "StickyNotes.snt" file in it, then rename it to "ThresholdNotes.snt so that the new path looks like: %LocalAppData%\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\Legacy\ThresholdNotes.snt This is explianed here: http://www.winhelponline.com/blog/recover-backup-sticky-notes-data-file-windows-10/ I have found the following info online where someone has apparently got USMT sucessfully migrating snt files to the correct location but I can't get it working: https://www.mail-archive.com/mdtosd@lists.myitforum.com/msg03057.html Has anyone successfully managed to migrate StickyNote files over in this way with USMT? Thanks, Westy
  15. Hi all, I have an application is SCCM that runs a vbs to install Office 2016 click to run. The packaging team have used a VBS so they can cover installing Office 2016 on different versions of Windows and also trigger the appropriate Office scrub tool if applicable. Anyway, in my instance I am running the application on a Windows 7 Enterprise X64 machine which has Office 2013 C2R already installed. If I run the script out of SCCM it upgrades O2013 to O2016 in around 15 mins but when installing via the SCCM Application it hangs sometimes for an hour before the actual install occurs. The smsts.log sticks at "Invoking App Management SDK to evaluate app polices" and I can see "officeclicktorun.exe" in the processes not doing anything. If I check ccmcache I can see an empty folder with the same time stamp as the last entry in the smsts.log so the download hasn't happened at this stage either. What is actually happening when the App Management SDK is invoking? Also, if I run the script as a legacy SCCM package it seems to work ok. The problem is just with SCCM Applications. I'm a bit miffed. Any help or advice would be gratefully received. Westy
  • Create New...