Replace Edge with Internet Explorer on Windows 10 (1607) via Task Sequence (Part II)

My most popular post is how I replaced Edge with IE in Windows 10. Since then, Microsoft made it a substantially easier in version 1607 to do this. IE is still a little wonky though as you'll see. I was able to take it down to two steps. Just the 'customize Start' and 'Copy IE Shortcut to Default Profile' steps. All the highlighted steps were removed and not needed anymore

I'll cover below as it could just be one step depending on your environment. My previous post is still worth a read as I wont rehash parts of it here and it covers some of the mechanics that still apply in 1607.

So what changed? Microsoft expanded how you can modify via the Export-StartLayout and Import-StartLayout PowerShell cmdlets. They have a good article about it here.

Task Bar

For the startbar modification I took the sample from the Technet article and added in the paths to the shortcuts so they get pinned (bolded below). There are some places you will NOT be able to point to such as %PROGRAMDATA% but know that %ALLUSERSPROFILE% points to the same location by default.

Additionally, you can append or replace based on the PinListPlacement element.

 <?xml version="1.0" encoding="utf-8"?>  
 <LayoutModificationTemplate  
   xmlns="http://schemas.microsoft.com/Start/2014/LayoutModification"  
   xmlns:defaultlayout="http://schemas.microsoft.com/Start/2014/FullDefaultLayout"  
   xmlns:start="http://schemas.microsoft.com/Start/2014/StartLayout"  
   xmlns:taskbar="http://schemas.microsoft.com/Start/2014/TaskbarLayout"  
   Version="1">  
  <CustomTaskbarLayoutCollection PinListPlacement="Replace">  
   <defaultlayout:TaskbarLayout>  
    <taskbar:TaskbarPinList>  
     <taskbar:DesktopApp DesktopApplicationLinkPath="%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessories\Internet Explorer.lnk" />  
     <taskbar:DesktopApp DesktopApplicationLinkPath="%APPDATA%\Microsoft\Windows\Start Menu\Programs\System Tools\File Explorer.lnk" />  
     <taskbar:DesktopApp DesktopApplicationLinkPath="%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Outlook 2016.lnk" />  
    </taskbar:TaskbarPinList>  
   </defaultlayout:TaskbarLayout>  
  </CustomTaskbarLayoutCollection>  
 </LayoutModificationTemplate>  

As the Technet article states, if you are unsure of the path you can pin it to the start menu and export it to get the path then put that under the taskbar section.

Taskbar is done and tested and was the whole fight in my last article. Way better right? Now onto the Start Menu.

Start Menu

For the Start Menu I setup a clean machine and organized it how I wanted and then exported it via the PowerShell cmdlet.

 Export-StartLayout \\server\path\to\LayoutModification.XML  

In my task sequence I then imported each XML but only the Taskbar was changed. Turns out you can only import ONE XML that manipulates the default desktop. So I had to merge them into one file. I split them thinking we may have a need to modify one over the other and since the Taskbar was imported second it trumped the Start Menu XML.

Heres the bonkers part. The IE shortcut for the Start Menu. This is how I learned that it does not honor %PROGRAMDATA% path to items. You are stuck in the majority to %ALLUSERSPROFILE% and %APPDATA% variable paths.

for my taskbar I am using "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessories\Internet Explorer.lnk" so I referenced that as well for the Start Menu section. Nope, does not work. %APPDATA% points to your roaming profile. My suspicion is that the Start menu is created a little earlier in the initial login process so it shows up blank due to the legacy profile paths are not created yet.

According to this MSDN article that f you are pointing to a third-party Classic Windows application, you must put the .lnk file in a legacy Start Menu directory before first boot. For example, "%APPDATA%\Microsoft\Windows\Start Menu\Programs\" or the all users profile located at"%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\". IE falls under this.

With that said though, I am able to point to the IE executable under %PROGRAMFILES%  and use this in the XML

 <start:DesktopApplicationTile Size="1x1" Column="0" Row="0" DesktopApplicationLinkPath="%PROGRAMFILES%\Internet Explorer\iexplore.exe" />  

It works, but ONLY for the first user to login. I think Windows modifies the imported XML to update it to %APPDATA%, which if you do an export right after login it reflects this.

 <start:DesktopApplicationTile Size="1x1" Column="0" Row="0" DesktopApplicationLinkPath="%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessories\Internet Explorer.lnk" />  

So on subsequent users logging in they do not get this icon. The first user is fine through all their logins. As many of my firms machines are used by multiple users, I decided to just copy the IE shortcut and point to that in my XML. As all the office shortcuts are put under "%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs" I just put the IE shortcut there. If you do not want to pin IE to the Start Menu then this is not needed. I have it pinned to both the Task Bar and Start Menu. For the Task Bar I could change to this precopied one or leave as is in the users profile.

Task Sequence

For the task sequence I just have two steps. The 'Customize Start' step is a PowerShell step that calls 'Configure-StartMenu.ps1' that just contains

 Import-StartLayout -LayoutPath .\LayoutModification.xml -MountPath $env:SystemDrive\  

The 'Copy IE shortcut to default profile' step simply copies the file from the package to the default users start.

 xcopy "Internet Explorer.lnk" "%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs" /E /C /I /H /Y  

I was done! Now that i know about the path issue for IE, the default Start can be updated within a few minutes.

Upon doing some final bare metal VM deployments, I noticed that a Start Menu shortcut for FireFox was missing. Who do we use during deployment? BUILTIN\SYSTEM. This makes me think further that the custom Start Menu is generated at login of ANY user after importation but not applied to an existing user. So by moving the 'Customize Start' step towards the end of the Task Sequence, this was resolved as it ran AFTER applications that are pinned to the Start Menu are installed, like FireFox.

-Kevin

Update OneDrive Next Gen Sync agent during Windows 10 Deployment

For my environment, the OneDrive Next gen sync agent is installed by Office 2016 Click-to-Run as it still Windows 7 for the majority. For the Windows 10 systems however its included in the OS and even with 1607 is now out of date. Instead of letting it update after deployment and presenting dialogs to the user, I thought I would update it via the deployment Task Sequence so its current right out of the box.

I chose to handle this via a simple BAT file thats really just 3 lines thats needed. Windows 10 keeps the OneDriveSetup.EXE  in %WINDIR%\SysWOW64 folder on 64-Bit systems and %WINDIR%\SYSTEM32 on 32-Bit. It is a 32-bit application so the File System Redirector handles how its presented. So first we need to find the file. Note that the Office install puts it under Program Files(x86)\OneDrive.

 IF EXIST %SYSTEMROOT%\System32\OneDriveSetup.exe SET ONEDRIVEPATH=%SYSTMEROOT%\System32\OneDriveSetup.exe  
 IF EXIST %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe SET ONEDRIVEPATH=%SYSTEMROOT%\SysWow64\OneDriveSetup.exe  

Since the file is owned by BUILTIN\TrustedInstaller we have to take ownership so SCCM is able to replace it.

 %SYSTEMROOT%\system32\takeown.exe /f %ONEDRIVEPATH%  

Now that we own it, we can modify permissions. Since its ran during the TS we are running as BUILTIN\System so lets give that account Full rights to the file. This allows us to delete and replace it.

 %SYSTEMROOT%\system32\icacls.exe %ONEDRIVEPATH% /Grant System:(F)  

Then simply copy the newer one. If your doing manually outside of a TS step you should use '%~dp0' variable.

 Copy OneDriveSetup.exe %ONEDRIVEPATH%  

The entire script is below if you want to just use it as is.

 @ECHO OFF  
 :: from https://kevinisms.fason.org  
 :: written by Kevin Fason  
 :: This will take ownership of OneDriveSetup.exe for Windows 10 so we can update it  
 :: Version 1.0  
 ::  Initial Release  
 :: February 6, 2017  
 ::  
 :: Locate it due to system32/Syswow64 switching per what bitlevel this scrip runs in  
 IF EXIST %SYSTEMROOT%\System32\OneDriveSetup.exe SET ONEDRIVEPATH=%SYSTMEROOT%\System32\OneDriveSetup.exe  
 IF EXIST %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe SET ONEDRIVEPATH=%SYSTEMROOT%\SysWow64\OneDriveSetup.exe  
 :: Make changes  
 :: Take Ownership  
 %SYSTEMROOT%\system32\takeown.exe /f %ONEDRIVEPATH%  
 :: Give BUILTIN\System Full rights  
 %SYSTEMROOT%\system32\icacls.exe %ONEDRIVEPATH% /Grant System:(F)  
 :: Replace the old one  
 Copy OneDriveSetup.exe %ONEDRIVEPATH%  

There are many other ways to handle something like this. Since this BAT is called from a wrapper there is zero checks and balances as the wrapper and ConfigMgr application handle that.  I chose an if then but you can use a goto statement as well for each bitlevel location. Doing it via Powershell is possible also however a BAT is alot simpler IMO. My co-worker Jason provided this as an example while still using built in executibles for the ownership and ACL work.

 $Path32 = $ENV:SYSTEMROOT + '\system32\OneDriveSetup.exe'  
 $Path64 = $ENV:SYSTEMROOT + '\syswow64\OneDriveSetup.exe'  
 if([System.IO.File]::Exists($path32))  
 {  
   [Environment]::SetEnvironmentVariable("ONEDRIVEPATH", $Path32, "Machine")  
   & c:/Windows/system32/takeown.exe /f $Path32  
   & c:/Windows/system32/icacls.exe $Path32 /Grant ("System" + ':F')  
 Copy-item ./OneDriveSetup.exe $Path32 -force   
   Write '32'  
 }  
 if([System.IO.File]::Exists($path64))  
 {  
   [Environment]::SetEnvironmentVariable("ONEDRIVEPATH", $Path64, "Machine")  
   & c:/Windows/system32/takeown.exe /f $Path64  
   & c:/Windows/system32/icacls.exe $Path64 /Grant ("System" + ':F')  
  Copy-item ./OneDriveSetup.exe $Path64 -force   
   Write '64'  
 }