none
Why do all Junction Points point to D:\<SomePath> and not C:\<SomePath> after deployment? RRS feed

  • Question

  • Running MDT 8456, ADK 1903, and Windows PE Add-on 1903

    Deploying Windows 10 LTSC 2019

    After deploying the image all Junction Points still exist, however, they are begin with D:\

    What cause this and how do I fix it?

    Tuesday, September 10, 2019 5:07 PM

All replies

  • Hello,

    Can you please elaborate your issue more ?

    Wednesday, September 11, 2019 12:21 PM
  • I have a golden image with Windows installed on C:. All junction points point back to C:. For example "C:\ProgramData\Application Data" points to C:\ProgramData. When this image is deployed to another computer with Windows installed on C: then the junction points are now pointing to D: such that "C:\ProgramData\Application Data" points to D:\ProgramData which doesn't exist.
    Wednesday, September 11, 2019 4:32 PM
  • Is your problem already solved? We are having exact the same issue.

    But we only have this problem on a deployment with images created after 10 October 2019.
    If we select a created wim before 10 October 2019 in the deployment TS, the junctioin points are pointing to C:\.
    With created wim's after that date, the junction points are pointing to D:\.

    When we look into the created wim's(all) they are all correctly pointing to C:\.

    Perhaps something to do with a patch(wsus) in the created image?

    Tuesday, November 19, 2019 9:49 AM
  • So we discovered this same issue recently on our 1809 images, where the junctionpoints point to a volume that doesn't exist.  We could never find the cause definitively, other than looking through our MDT logs, when the system is in PE, it seems that the "Wrong" drive letters are what PE was using at the time, why that has anything to do with restoring a .wim is beyond our imagination.  Anyhow, we use powershell "expand-windowsimage" to restore our .wim's.  We found when we use the -NoRpFix switch(which seems counter-intuitive) option to restore the wim, the junction points come out correctly.  DISM and imagex also have NoRpFix switches. Good Luck. 
    Wednesday, December 11, 2019 3:08 PM
  • We are having the same issue with Windows 10 1809. It was working up until a couple of weeks ago.

    What gives?

    TrickyPicky75, where are you running the powershell "expand-windowsimage"? Thanks.

    Thursday, January 2, 2020 8:37 PM
  • So, we use a PS Script instead of the "Install Operating System" task to deploy our images with MDT.

    Also since my last post.  While the -NoRPFix seemed to correct the issue on all most all of our deployments.  We had one stubborn image that still was coming up with wrong Junction points after it was deployed.  I pulled up the Audit image and found that the Junction Points were actually screwed up in the image.  Currently working on writing a script to automate finding, deleting, re-creating, and correcting permissions; ownership; and attributes of the Junction Points.

    Thursday, January 9, 2020 8:53 PM
  • We have seen the same behavior. We don't know why this happens, but it seems to be a random problem. I can image the same test computer four times and everything looks good and the next time I image the computer, the junction points are incorrect. 

    I have implemented a script in the task sequence, right after the format and partition step, that uses the Powershell storage cmdlets for WinPE. The script looks at the partition to get the assigned drive letter. If it is not C:, then I use a Cmdlet to change the assigned drive letter to c:. The storage cmdlets are much easier to work with than using diskpart. 

    Monday, January 27, 2020 8:12 PM
  • I have encountered a very similar issue as well, where the junction points in C:\ProgramData are invalid. Also running MDT 8456, ADK 1903, and WinPE for 1903, however I am deploying 1809. Didn't have the issue until after patch Tuesday this month. I believe that KB4532691 has a bug that is breaking junction points for certain deployments of 1809. My 1909 deployments are unaffected. I am using an 1809 English x64 ISO directly from Microsoft's website. This problem causes some software, in my case ShoreTel Communicator 14.2, to fail installation.

    Context: I work at a University with multiple campuses. I am the local IT person at my campus. I wholly own our MDT deployment share that is used by all campuses for client deployments. I implemented MDT for the first time about 7 months ago to replace an old method of imaging. We deploy MDT using flash drives, as our network is not robust enough to effectively handle network-based deployments.

    Here are two scenarios that I can reproduce the problem 100% of the time, but the TLDR is that if KB4532691 is installed in my reference images, it breaks the junction points at C:\ProgramData

    Scenario 1:

    Import virgin OS files from the 1809 ISO into an MDT deployment share. Create a reference image of 1809 and let ZTIWindowsUpdate install all available updates from Microsoft's servers. Verify that the junction points are working properly. Capture this into a WIM file. Import the WIM file into another deployment share in MDT. Deploy the 1809 TS onto a VM or physical machine using a USB drive. Upon first boot after OOBE, open the command prompt. Execute "dir C:\ProgramData /al" and observe that the junction points here point to another drive, in my case E:

    Scenario 2:
    Download KB4532691 for 1809 x64 (full file name: windows10.0-kb4532691-x64_6cc9bd762dba5f7f692321efae5386700de3bf94.msu). Use the USBUpdate Powershell script from Kari at TenForums to integrate KB4532691 into the virgin OS files taken from the 1809 ISO. Import the updated OS files into an MDT deployment share. Create a reference image of 1809, but disable the TS steps that run ZTIWindowsUpdates. Capture this into a WIM file. Import the WIM file into another deployment share in MDT. Deploy the 1809 TS onto a VM or physical machine using a USB drive. Upon first boot after OOBE, open the command prompt. Execute "dir C:\ProgramData /al" and observe that the junction points here point to another drive, in my case E:

    Scenario 3 (workaround):
    Import virgin OS files from the 1809 ISO into an MDT deployment share. Create a reference image of 1809, but disable the TS steps that run ZTIWindowsUpdates. Do not install any Windows Updates. Verify that the junction points are working properly. Capture this into a WIM file. Import the WIM file into another deployment share in MDT. Deploy the 1809 TS onto a VM or physical machine using a USB drive. Upon first boot after OOBE, open the command prompt. Execute "dir C:\ProgramData /al" and observe that the junction points here are valid and reference C:. Use ZTIWindowsUpdate or the normal Windows Update routine and let it download all available updates, including KB4532691. Verify that all junction points at C:\ProgramData are pointing to C:

    Is anyone else able to repro this? I've spent a lot of time testing and haven't found anything that points to a problem with my deployment shares so far. As I was doing my Google research, I found that CVE-2020-0733 makes reference to junction points.
    It would seem logical to conclude that changes made to fix this may be causing the issue I am experiencing, however this CVE is linked to KB890830, NOT to KB4532691, so not sure what to make of it.


    Wednesday, February 26, 2020 5:21 PM
  • Any chance you could provide the script you use?
    Wednesday, February 26, 2020 7:36 PM
  • There seems to be a bug in the MDT imaging process, in the standard Task Sequence the "Format and Partition Disk (UEFI)" Task formats the disk and assigns volumes the "next available drive letter" this shouldn't be an issue as by default the OSDPreserveDriveLetter variable is set to True meaning whatever main drive letter was on the image when captured should be applied during deployment. So if your reference image has C:\ as it's main drive so will any new deployments. 

    The issue is that for some reason when the image is being applied junction points retain the drive letter that the "Format and Partition Disk (UEFI)" task originally chose for the primary windows drive. The workaround I have in place is simply to disable this task and create my own that will always assign the primary partition to the C drive. Here is the powershell script I am using:

    $Script:TaskSequenceEnvironment = $null
    $Script:TaskSequenceProgressUi = $null
    $global:progressPreference = 'silentlyContinue'
     
    function Confirm-TSEnvironmentSetup()
    {
        <#
        .SYNOPSIS
        Verifies the TSEnvironment Com Object is initiated into an object.
        
        .DESCRIPTION
        Verifies the TSEnvironment Com Object is initiated into an object.
    
        .INPUTS
        None
    
        .OUTPUTS
        None
        
        .NOTE
        This module can be used statically to initiate the TSEnvironment module, however, simply running one of the commands will initate it for you.
    
        #>
    
        if ($Script:TaskSequenceEnvironment -eq $null)
        {
            try
            {
                $Script:TaskSequenceEnvironment = New-Object -ComObject Microsoft.SMS.TSEnvironment
            }
            catch
            {
                throw "Unable to connect to the Task Sequence Environment! Please verify you are in a running Task Sequence Environment.`n`nErrorDetails:`n$_"
            }
        }
    }
    
    function Confirm-TSProgressUISetup()
    {
        <#
        .SYNOPSIS
        Verifies the TSProgresUI Com Object is initiated into an object.
        
        .DESCRIPTION
        Verifies the TSProgresUI Com Object is initiated into an object.
    
        .INPUTS
        None
    
        .OUTPUTS
        None
        
        .NOTE
        This module can be used statically but is intended to be used by other functions.
    
        #>
        if ($Script:TaskSequenceProgressUi -eq $null)
        {
            try
            {
                $Script:TaskSequenceProgressUi = New-Object -ComObject Microsoft.SMS.TSProgressUI
            }
            catch
            {
                throw "Unable to connect to the Task Sequence Progress UI! Please verify you are in a running Task Sequence Environment. Please note: TSProgressUI cannot be loaded during a prestart command.`n`nErrorDetails:`n$_"
            }
        }
    }
     
     
     function Show-TSActionProgress()
    {
        <#
        .SYNOPSIS
        Shows task sequence secondary progress of a specific step
        
        .DESCRIPTION
        Adds a second progress bar to the existing Task Sequence Progress UI.
        This progress bar can be updated to allow for a real-time progress of
        a specific task sequence sub-step.
    
        The Step and Max Step parameters are calculated when passed. This allows
        you to have a "max steps" of 400, and update the step parameter. 100%
        would be achieved when step is 400 and max step is 400. The percentages
        are calculated behind the scenes by the Com Object.
        
        .PARAMETER Message
        The message to display the progress
    
        .PARAMETER Step
        Integer indicating current step
    
        .PARAMETER MaxStep
        Integer indicating 100%. A number other than 100 can be used.
    
        .INPUTS
         - Message: String
         - Step: Long
         - MaxStep: Long
    
        .OUTPUTS
        None
    
        .EXAMPLE
        Set's "Custom Step 1" at 30 percent complete
        Show-TSActionProgress -Message "Running Custom Step 1" -Step 100 -MaxStep 300
        
        .EXAMPLE
        Set's "Custom Step 1" at 50 percent complete
        Show-TSActionProgress -Message "Running Custom Step 1" -Step 150 -MaxStep 300
    
        .EXAMPLE
        Set's "Custom Step 1" at 100 percent complete
        Show-TSActionProgress -Message "Running Custom Step 1" -Step 300 -MaxStep 300
    
    
        #>
        param(
            [Parameter(Mandatory=$true)]
            [string] $Message,
            [Parameter(Mandatory=$true)]
            [long] $Step,
            [Parameter(Mandatory=$true)]
            [long] $MaxStep
        )
    
        Confirm-TSProgressUISetup
        Confirm-TSEnvironmentSetup
    
        $Script:TaskSequenceProgressUi.ShowActionProgress(`
            $Script:TaskSequenceEnvironment.Value("_SMSTSOrgName"),`
            $Script:TaskSequenceEnvironment.Value("_SMSTSPackageName"),`
            $Script:TaskSequenceEnvironment.Value("_SMSTSCustomProgressDialogMessage"),`
            $Script:TaskSequenceEnvironment.Value("_SMSTSCurrentActionName"),`
            [Convert]::ToUInt32($Script:TaskSequenceEnvironment.Value("_SMSTSNextInstructionPointer")),`
            [Convert]::ToUInt32($Script:TaskSequenceEnvironment.Value("_SMSTSInstructionTableSize")),`
            $Message,`
            $Step,`
            $MaxStep)
    }
     
    #Export-ModuleMember -Function Show-TSActionProgress 
    
    
    $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
    
    $tsenv.Value("OSDisk") = "C:"
    
    $tsenv.Value("DestinationOSVariable") = "C:"
    
    $tsenv.Value("OSDTargetDriveCache") = "C:"
    
    
    $Disks=@((Get-Disk).Number)
    
    Show-TSActionProgress -Message "Cleaning and Formatting Disks" -Step 1 -MaxStep 5
    
    Foreach($Disk in $Disks){If(((Get-Disk -Number $Disk).PartitionStyle) -ne "RAW" -and ((Get-Disk -Number $Disk).bustype) -ne "USB" ){Clear-Disk -Number $Disk -RemoveData -RemoveOEM -Confirm:$false}}
    
    Foreach($Disk in $Disks){Initialize-Disk -Number $Disk -PartitionStyle GPT}
    
    Show-TSActionProgress -Message "Creating System EFI Boot Partition" -Step 2 -MaxStep 5
    
    New-Partition -DiskNumber 0 -GptType "{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}" -Size 499MB -DriveLetter "S"
    Format-Volume -FileSystem FAT32 -NewFileSystemLabel "SYSTEM" -DriveLetter "S" -Force
    
    Remove-PartitionAccessPath -DiskNumber 0 -PartitionNumber 1 -AccessPath S:
    
    Show-TSActionProgress -Message "Creating System Reserved MSR Partition" -Step 3 -MaxStep 5
    
    New-Partition -DiskNumber 0 -GptType "{e3c9e316-0b5c-4db8-817d-f92df00215ae}" -Size 128MB
    
    Show-TSActionProgress -Message "Creating Main Windows Partition" -Step 4 -MaxStep 5
    
    New-Partition -DiskNumber 0 -UseMaximumSize -DriveLetter "C"
    Format-Volume -FileSystem NTFS -NewFileSystemLabel "Windows" -DriveLetter "C" -Force
    
    Show-TSActionProgress -Message "Checking For And Initializing Additional Drives" -Step 5 -MaxStep 5
    
    Foreach($Disk in $Disks){If($Disk -ne "0"){$TLetter= ls function:[d-i]: -n|?{!(test-path $_)}|Select-Object -First 1; $Letter = $TLetter -replace ":";
                                               New-Partition -DiskNumber $Disk -UseMaximumSize -DriveLetter $Letter;
                                               Format-Volume -FileSystem NTFS -NewFileSystemLabel "Data" -DriveLetter $Letter -Force}}
    
    exit
    
    




    PLEASE NOTE: This Script Does not include a Recovery Partition and is for UEFI Only, I have no use for legacy / Recovery Partitions so I didn't include them in my script. Also full disclosure, I am using several functions that I did not write myself simply re-purposed. I would credit the authors but I do not remember where I got them from. 

    In order to get this working please follow these instructions:

    1. As a prerequisite ensure that your winPE environment has the following features enabled (DISM Cmdlets, Windows Powershell, Storage Management Cmdlets)
    2. Disable both Format and Partition Disk tasks in your sequence
    3. Create a new Run Powershell Script task in the same location as the previous formatting tasks and point it to a location you've placed the script above
    4. Test the solution

    (Optional)

    This will fail if there is anything on the disk prior to imaging, you will have to run a diskpart / clean command to have the image work successfully. Having to do this manually for every computer you image can become tedious very quickly so I would suggest editing your win_PE unattended.xml file and add a new runsynchronouscommand pointing to a batch file containing the proper diskpart commands. This way every computer that boots into the win PE environment will automatically be cleaned. This will also prevent you from experiencing any "dirty environment" issues. 

    Taking these steps will ensure that your junction points are pointing to the correct drive, if you require a recovery partition you can easily create one by modifying the above script using the same logic. You can also change it from using GPT to MBR if you require. 

    If you require assistance in getting this to work, you can contact me directly. 












    Saturday, March 14, 2020 8:41 PM
  • Seeing this behavior only with offline USB deployments. MDT version 8456, and the 1809 ADK. Looks like there have been a couple report solutions or work around. Is there a concuss on cause and best fix/workaround.
    Sunday, April 19, 2020 9:15 PM
  • See my answer above for the best working solution, I have been using this script for months with 0 issues. 

    The start of my answer above also explains what's happening, as to why it's occurring on specific versions of windows? I am not completely sure... 

    Thursday, April 23, 2020 2:29 PM