SighBee

I updated our SCCM deployment to 1810 last week, including installing Hotfix Rollup KB4486457 and Hotfixes KB4490575 and KB4490434. Now we seem to have duplicate user resource objects. The main difference between the two objects is the newly-created object only has the "SMS_AD_USER_DISCOVERY_AGENT" listed in "Agent Name" in the properties of the resource whereas the original object additionally has "Intune_User_Discovery_Agent" listed. Other differences include the "Agent Time (UTC)" property: the new object has a recent timestamp (today) but the original has two timestamps (one from before the upgrade and the other from last year); the "Creation Date (UTC)" property and "Resource ID" are obviously different also. I don't think we've hit this: https://support.microsoft.com/en-gb/help/4490434/duplicate-user-discovery-columns-in-configuration-manager. The SQL query yields no results. One thing that is strange is if I look at the "Updates and Servicing Status" for the last two hotfixes, they both show "Post Installation" as "In progress" despite both having an overall status of "Installed" (see attachment for example). Does anyone know what might have happened and how to fix? Which object should we get rid of and what's the best way to do this in bulk? Many thanks in advance!

I've just run into this. I found a thread on Reddit where a "MSFT Official" says this is a bug which is fixed in 1810: https://www.reddit.com/r/SCCM/comments/9fvol5/nupxe_not_booting/

Check out https://github.com/OfficeDev/Office-IT-Pro-Deployment-Scripts/tree/master/Office-ProPlus-Deployment/Remove-PreviousOfficeInstalls. I've created a package and just run the Powershell script with appropriate parameters and it works very well.

Thanks for the response simulacra75! A Spectre/Meltdown issue with the missing version was my thought as well. So, it turns out that a couple of BIOS settings can cause this issue (on this particular model). Firstly, disabling the "Disable UEFI Network Boot" step allowed the TS to proceed past the first reboot. I then had the same issue after disabling "Thunderbolt Pre-Boot Module" (despite not even having a Thunderbolt device connected) in a later step. I worked around the issue by moving one step to later in the TS, creating an additional one and adding some filtering.

I'm seeing some weird behaviour when building a new Dell Latitude 7490. Boot List Option is set to UEFI and I've tried this with SATA Operation mode in both AHCI and RAID On. I PXE boot the laptop and start my OSD TS which sets some more BIOS settings (disable UEFI Network Stack, disable Legacy Option ROMs and enable Secure Boot). It then formats the disk with GPT partitions (700MB FAT32 Primary with TSUEFIDrive variable and 100% of remaining space NTFS Primary) and reboots. The laptop goes through POST, displaying the Dell splash screen and then just powers off as if there are no boot options available. If I start the laptop again, it'll keep doing the same thing until I either press F12 and select the HDD (and M.2 SATA SSD) to boot from or simply just enter and exit the BIOS. If I do either of those, WinPE loads and the TS continues as normal. I've tried various workarounds including setting "cctk.exe bootorder --bootlisttype=uefi --sequence=hdd --enabledevice=hdd" and different combinations of BIOS settings but I can't get past this problem. When the laptop was first built, the BIOS was upgraded from 1.1.6 to 1.2.6 as part of the task sequence (I don't remember if I encountered the above problem that first time) but I'm not able to downgrade to any of the previous versions. *EDIT - Forgot to mention that 1.2.6 is no longer available on Dell's website with no mention of why.* Any ideas? Could this be a bug with the BIOS firmware? Thanks in advance!

I'm running this after the Setup Windows and Config Manager step with the following Run Command Line step: Powershell.exe Import-StartLayout -LayoutPath StartMenu.bin -MountPath C:\ What command are you using?

Hey junderkofler. I'm not sure exactly what fixed the issue in our case but I ended up uninstalling and reinstalling the client and eventually the upgrade worked (following install of Windows updates and a reboot). It was just a really unusual case with the upgrade partially failing. Normally, it either just works or bombs out and rolls back.

I posted this yesterday in the "How do I?" forum (not sure I can delete it) but thought it probably belongs here. Apologies if this is frowned upon. I have a task sequence to run an in-place upgrade to Windows 10 and it's run successfully on nearly 100 machines. However, one machine has just encountered an error I can't decipher. According to smsts.log, it completed the first part of the upgrade on Friday evening (today is the following Monday) and then rebooted but the next entry isn't until this morning, which is strange. I'm not sure if the machine crashed but it appears not. When the user logged on this morning, Windows 10 was in a funny state with no start button and no network connectivity. Rebooting the laptop initiated a rollback and the PC is back working correctly on Windows 7. Anyway, onto the error: when the log continues, there appears to be an "access denied" error when trying to load the TS environment: Can anybody explain what is generating the error and how I can fix it? Thanks!

Are you pressing F12 a second time to network boot?

My upgrade TS doesn't inject any drivers and I rely on the Windows 10 in-box driver store. There was a minor issue during the pilot with a touchpad driver for a particular set of laptop models but I just pushed out an application to those models to update before I rolled out the TS more widely. If you're particularly worried about driver compatibility, find out what driver versions are currently installed and check their compatibility with Windows 10. A lot of recent drivers seem to be supported on Windows 7/8.1 as well as Windows 10 so you might be ok. If there are any that aren't, set up some apps to update them, then roll out the TS without the driver install.

I've set up a task sequence to run an in-place upgrade to Windows 10 and it's run successfully on nearly 100 machines. One machine has just encountered an error I can't decipher. According to smsts.log, it completed the first part of the upgrade on Friday evening (today is the following Monday) and then rebooted but the next entry isn't until this morning, which is strange. I'm not sure if the machine crashed but it appears not. When the user logged on this morning, Windows 10 was in a funny state with no start button and no network connectivity. Rebooting the laptop initiated a rollback and the PC is back working correctly on Windows 7. When the log continues, there appears to be an "access denied" error when trying to load the TS environment: Can anybody explain what is generating the error and how I can fix it? Thanks!