sparkeh

@robsonma here's how I did drive maps. First of all I created the drive mapping in a GPO and then a shortcut to the drive mapping. I actually created an msi which runs at OS deployment and puts the shortcuts in the right place (for me the %allusersprofile% startmenu) before the first login. I then added the following to the xml Off the top of my head, I would think that you have to add the shortcut to the %allusersprofile% start menu - as I understand it, there is a database that contains the DesktopApplicationID's and when you add a shortcut to the %allusersprofile% or your own profile's start menu it generates the ID. So when I add the U:\ shortcut it generates the ID "U:" which you can use in the xml. If you put the shortcut anywhere else it won't know about it when you call it. At least that's how I understand it.

Anything in the event logs about not being able to contact a domain controller? I have a similar issue with some of our machines with SSDs booting too quickly so the NIC isn't initiliased in time. This means that it can't contact a DC so skips group policy processing. Once it contacts a DC it gets the policy.

Just don't put anything in the 'profile path' box on the 'Profile' tab of a users record in AD. When the user logs on a local profile will be created.

Yeah, but profile creation on first login in only a few seconds slower than subsequent logins so not an issue (with Modern Apps removed - they have a big overhead).

Not if you disable it via GPO Computer Configuration > Administrative Templates > System > Logon > Show first sign-in animation And with all the Modern Apps stripped out of the install.wim even the first login is pretty darn quick. Its never been an issue for us.

XML as requested

Sorry, what issue?

Local profiles have never been an issue for us.

I second this actually. I always have to remove the %20. There's a MS blog post about it somewhere, I'll try and dig it out when I'm not out and about.

+1 So, so funny [emoji23] great post credits bit as well

@pennyl welcome!

Thanks, this exact issue was on my list for Monday [emoji3] MS really are about the xml at the moment! GPPs were great for this [emoji20]

For DA you would need the device on site to add to AD and pick up the DA GPOs. Using an MDM this is not necessary

I think that this is what you need: https://blog.thomasmarcussen.com/installing-net-framework-3-5-with-mdt-2013-the-simple-way/ This is how I do it [emoji3] Edit: article written for win 8 but method the same.

Doesn't satisfy the 'never on site' requirement. With an MDM you can configure and manage the device without it ever coming on site. I can't see how you can do that with AD + DA but please correct me if I am wrong?

The OP asked about laptops that are rarely or never on site. AD and GPO won't help there. MS are pushing InTune for this and there's other MDMs that could be used as stated above.

If the drivers are of the setup.exe variety then you can create a package and run it silently on the client. If is just the bunch of files variety then you can leverage pnputil.exe as per: http://ccmexec.com/2013/10/update-a-device-driver-configuration-manager-2012/

I think that Utd could do it as well. Lukaku, Matic (can't believe they let him go to Utd) and, apparently, Zlatan back if his knee recovers... I think they look good

@ADMaster Thanks, you are a bona fide legend!

Looking forward to this season more than I have for a while. Looking quite open and should be a handful of teams in with a shout.

Having just gone through the process of updating SCCM for (and deploying) Window 10 v1703 I thought that I would share what I did and what I learned in case it helps anyone. SCCM will now be updated along with the release of new Windows 10 builds. This means that you will also need to update to the ADK released with the new Win 10 build and possibly MDT (though this won't be updated for every build, just as needed). Although its not strictly necessary to have everything aligned like this, it is recommended. There is however a handy chart of supported configurations here You can find the latest ADK here: https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit Update ADK first! When you update SCCM it will generate new boot disks. If you have already updated ADK then you will get updated boot disks based on the new ADK. If you don't then you get boot disks based on the old ADK. You can check if you have the latest boot disks by comparing the version of the boot disks in SCCM to the version of ADK in add/remove programs: If you do update SCCM first you can regenerate the boot disks to be based on the update ADK with this handy script: https://gallery.technet.microsoft.com/RegenerateBootImageWinPE10-f508f1e4 After this you can update SCCM from the console Next check if there is an update to MDT here: https://technet.microsoft.com/en-us/windows/dn475741.aspx?f=255&MSPPError=-2147217396 If there is an update to MDT then install it and remember to integrate it into SCCM again. Also remember to create a new MDT tookit and setting package and a new USMT package (easiest way is to create an MDT TS and let it create the package) [*]Now you can download your chosen Win 10 build from MSVLC. At this point I use @Arthur's script to strip out the unwanted Modern Apps from the install.wim and then import into SCCM. Slight gotcha here as I learned that when you update ADK you get a new version of DISM, but its installed side-by-side with any existing versions allowing you to swap between them. You can use import-module to use the version you want. [*]You also need to update any language packs that you are deploying, these are also available from MSVLC. After this you should be go to go and update your deployment TS to reflect the new source, boot disks, MDT packages, lang packs etc.

I'm conscious that this thread has been derailed from @Michael's method for using Classic Shell so I have created a new topic for the native menu discussion: http://www.edugeek.net/forums/windows-10/187278-successfully-deploying-start-menus-windows-10-v1703.html

So after pulling my hair out trying to achieve this in earlier builds, it appears that v1703 brings stable Start Menu deployment. As there are numerous, disparate posts on this I thought I would share my method in case it helped anyone. This info was garnered from lots of members here (including @Arthur @thimon @Blue_Cookeh @win amoungst others) and a hell of a lot of reading about v1703 So, here's what I have learned: Use v1703 - for me this is only build that I can get to work properly. Don't use roaming profiles or redirected Start Menus (I know that some people report success with these but MS have stated that these are not supported with applying start layouts via gpo) Modern apps that you decide to keep need to be referenced by the AppUserModelID attribute in the xml. Apps that are installed before the first boot (eg during a SCCM deployment) can be referenced via the DesktopApplicationLinkPath attribute in the XML. Shortcuts need to be in the all users start menu located at %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs (I have a couple of bits of software that don't install their shortcut properly so I just created an msi to deploy after software installation to correct it). Apps installed after first boot need to be referenced by their AppID in the DesktopApplicationID attribute in the xml. You can get a list of AppIDs by running the get-startapps powershell commands. This specially highlighted for v1703 by MS in one of their guides. When tested I found that contrary to the old problem of missing tiles, new tiles were added dynamically (ie there is a missing tile at logon which then is replaced by the correct tile as you look at it), this seems like a new feature, at least one that I didn't see before. The DesktopApplicationID attribute can be used to reference web urls and other things such as shortcuts to mapped drives. The limits stated by MS about the size of groups that you can create appears not to be correct as I have added more tiles than the stated limit. If you add more tiles you get a scrollable Start Menu as you still cannot set the size of the tile area, which is quite annoying. Learning the structure of the xml file and editing it directly is easier than faffing around exporting a Start Menu (also the export command always output references to apps as DesktopApplicationLinkPath which you might need to edit anyway) Using the above seems to deliver a stable and manageable Start Menu without the issues of missing tiles and borked menus that plagued previous build. Here is an example of a simple Start Menu: Here's some more reading: https://docs.microsoft.com/en-us/windows/configuration/customize-windows-10-start-screens-by-using-group-policy https://docs.microsoft.com/en-us/windows/configuration/windows-10-start-layout-options-and-policies https://docs.microsoft.com/en-us/windows/configuration/customize-and-export-start-layout https://docs.microsoft.com/en-us/windows/configuration/start-layout-xml-desktop <- good one to reading up on

@mdrabble Mind sharing how you got the drive maps to show - mine just get ignored and don't show up. EDIT: Nevermind I got it sorted

Agreed, you'll have less problems if you deploy from source media and configure afterwards