nathan_bird

Yes Garth but that doesn't give the me the current Build Number (as listed on release info TechNet page) I'll plug away at it, there has to be a way https://technet.microsoft.com/en-gb/windows/mt679505.aspx?ocid=wc-ext-aka

Either. If I can give my security manager a list of W10 machines and their current CU Level each month he's happy. If its a collection I can pull the members for each via PowerShell. If its a SQL Query then i'll build a simple report.

Hi All, Apologies if I've missed it elsewhere (Numerous Google searches drew a blank too) but has anybody got a query for the Current CU Level of a Windows 10 build? The version displayed in "winver" I know I can do a search on the KB Article via Quick Fix Engineering in WMI but if a machine has multiple CU's installed it shows in more than one collection. I want individual collections based on the CU OS Build Number. i.e 14393.105 (Windows 10 1607 with KB317493) Any pointers would be appreciated. Cheers!

In a word....Yes.

Remove your site system proxy settings. Restart dmpdownload component. Re-add proxy settings and restart dmpdownload again. I have had issues with 1606 downloading updates. Messing about with proxy settings fixed it

I had another 1511 environment that would just not upgrade. (this was after my post above regarding being patient) It hung at "Installing" although it was doing nothing. So i tried to install it the old way.....via install files that download to the EasySetupPayload folder. Failed, wouldnt run. Resolution - Copy the contents of the EasySetupPayload folder to the another drive and run it, worked just fine. This was after logging a support case with MS who basically didn't know what was causing it, they gave me the OK to try this method. So it is supported I suppose. Anyway i have no issues with this environment after running the upgrade this way. It'll be one im noting for future reference thats for sure.

I replied to your other post on the D Drive Question. Perhaps its best to combine these 2 posts if you can.

Just leave it in and point it to the image file you are deploying. With UDI ensure you have configured the Site Settings to your Primary Site (Ribbon item when you are in the Edit Volume Step) *sorry doing this from memory on a mobile device hence no screenshots

Are you using MDT Boot Images? If not my suggestion would be integrate MDT and use them. You'll have alot more success, all you'll need to do is add the Surface Network Drivers to the them. Storage is covered OOB in most cases (Surfaces definitely) I am imaging SP3 and 4 devices with 1602 and MDT 2013 Update 2........Zero Issues.

I've seen this happening on Windows 7 x64 clients. A re-install/upgrade of the SCCM Client fixed it in my case.

Did you re-distribute the package to your DP after making the changes? The D Drive is always listed as the Primary Drive as the UDI runs in Windows PE (the WinPE partition takes letter C). Disable the "Set Variable for Drive Letter" step in the Task Sequence And make sure your variable in your Partition and Apply Operating System steps is consistent usually OSDisk. The task sequence will then ensure (post WinPE) that the image is applied to C. You'll get there in the end with UDI's, it took me ages to puzzle all the pieces together. There is next to zero documentation on this direct from Microsoft which doesnt help matters.

Can leave them, if you make a change to any of the steps the change will be made to each scenario

I've replied to your post, hope it helps. I would start from scratch and build new MDT Toolkit and Settings Packages. My ADK Version is 10.0.26624

Looks like you've removed the Volume page or the whole New Computer stage from the Wizard (so it doesn't know what Image you are deploying) Mine is attached and works seamlessly. Bear in mind you need to use variables in CustomSetttings.ini file if you want to lock down your domain join credentials (New Computer Details step)

You will use the tools from whatever version you are migrating to as you set up the Migration Source to your old site at the new site (these are compatible across all 2012/CB versions) I used the following VBS script to update the site code on clients On Error Resume Next set oSMSClient = CreateObject ("Microsoft.SMS.Client") if Err.Number <>0 then wscript.echo "Could not create SMS Client Object - quitting" end if 'Assign client to Servername oSMSClient.SetAssignedSite "YOURNEWSITECODE",0 set oSMSClient=nothing We did lose a slight bit of client history as its a new DB but we were happy with that, we had made it clear SW and HW Inventory information would need to be given time to fully re-sync. So i would say make sure you arent doing this during important SW Audits or License True Ups. My suggestion would be build a new 1511 site, then upgrade it straight away to 1602. Then migrate. This way you only have 1 Client Upgrade push to perform to your estate (at the time of writing ) I'm already running 1602 in production without issue.