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.

UDI with 1602 works fine for me (MDT 2013 Update 2). Im using this in production for imaging of Windows 7, 8.1 and 10 x64 bit machines.

I had the same issues. In the end i just left it overnight in frustration, low and behold it completed without issue and with all relevant log files updated. dmpdownloader.log, ConfigMgrPreReq.log and CMUpdate.log. No idea why it hung, just have to play a patience game as you do with most things SCCM.

Suppose it depends on what exactly you want to achieve. I use the UDI functionality for our production task sequences, this is due to every install we do being different (in terms of apps) and we have to support 12 languages.

Ensure your boundaries and boundary groups are configured correctly

Bit generic..... Are they all failing for the same reason? what is CCMSetup.log saying on these clients?

I deployed a .vbs to change the Site Code - worked well for 5k machines. Can do this via SCCM itself or via GPO up to you. 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 "SITECODE",0 set oSMSClient=nothing Obviously just amend the SITECODE to your new one Hope this helps.

Same issue being experienced here. Be interested to hear if you managed to get it resolved or not?

This is easily acheivable, i've done this with my own production environment (i inherited 1 x CAS and 5 x PS's managing just 5k clients ) Here's what i did and it worked seemlessly. 1. Built a brand new 2012 R2 Server (use the same Service Accounts to make life easier and make sure you give it the correct AD permissions etc) 2. Installed SCCM with a new Site Code (install 1511 and you'll cover an upgrade at the same time if you havent already done this, mine was a 2012 R2 to 2012 R2 SP1 upgrade) Optional but I took the opportunity to install my new DB on a SQL 2014 SP1 Cluster (before each site had its own local SQL DB running SQL 2k8 r2 which also got me on the DBA's Christmas card list ) 3. Used the built in Migration Tools (Sharing your DP's until you are happy to move them over) to migrate my Task Sequences, Packages, Apps, Client Settings, boundaries etc over to the new environment 4. You then have a number of options for moving over your clients. I fired a Site Code change script as each PS's clients, once they were reporting to the new site i decomm'd each PS and then the CAS. Basically do a full side by side installation. Took me about 8 weeks as i took my time to do it, didnt want to introduce too much change at once. There was minimal downtime no hiccups which kept my ServiceDesk happy. Obviously this is very high level but if you need any more info. Let me know.

There's a bug that has existed with the MDT Toolkit and this still exists in MDT 2013 Update 2. See following which details how to work around it: http://thedesktopteam.com/raphael/sccm-2012-r2-and-mdt-2013-udi-locale/

Presuming you have updated your Unattend.xmlf were you aware there has been a bug around since MDT 2012 Update 1 with the UDIWizard.wdf file within the MDT Toolkit.......Yes this still exists in MDT 2013 Update 2! Credit goes Raphael at the The Desktop Team: http://thedesktopteam.com/raphael/sccm-2012-r2-and-mdt-2013-udi-locale/ I was pulling my hair out a couple of years back with my XP to Win 7 upgrades, fix still required for all versions of MDT 2013. Hope this helps.