ProgramData folder junction breaks after upgrade to 1709












6














We have a custom image on 100's of PC's across the country that uses disk protection, and in order for our management platform software to update and work correctly, we had to create a junction to a drive that is not protected by disk protection.



The issue is this: When one of our PC's updates to 1709, it breaks those junctions we have set up, and we're then not able to access the PC to fix the other things 1709 breaks (such as overwriting our custom recovery environment, resetting default programs etc) because the program data folder is then bricked so our management software is unable to function correctly.



I was wondering if anyone else has encountered a similar issue and has found a fix, as we cannot spare the man hours to upgrade 100's of pc's to 1709 and then manually fix what gets broken.










share|improve this question




















  • 1




    In all likely hood it's an unsupported change. An example on how to fix it would be to deploy a script or use something like remote PowerShell. With such little information it's hard to tell what options you have available. As it is, don't let them update and prepare a 1709 image and deploy that instead?
    – Seth
    Jan 8 '18 at 19:05






  • 1




    In normal environments that honestly would probably be the best solution. However these are standalone PC's, that are used as kiosk machines. We update/maintain them via procedures that we setup on our management platform. So when we update them to 1709, and the junction breaks, we loose all management control via our platform and have to use a 3rd party remote app (similar to TeamViewer) to connect back and then manually fix the issues. If we're able to prevent/fix the junctions from breaking, then the rest is easy.
    – ztnd13
    Jan 8 '18 at 19:09










  • Was this junction in place with the last major update or have you switched to Win10 after that? Personally I'd expect it to break with major updates. It does look like moving ProgramData is actually supported, I'm assuming its on the same kind of drive? related.
    – Seth
    Jan 8 '18 at 19:20










  • Here's the scenario: PC running Windows 10 Pro x64, (version 1607 or 1703) C:programdataOursoftware junction in place, linked to D:ProgramdataOursoftware. When the PC updates to 1709, that junction gets broken.
    – ztnd13
    Jan 8 '18 at 19:28










  • So you didn't move the ProgramData folder as a whole, OK. What disk protection are you using? How does it work in conjunction with the update? Do you disable it beforehand and enable it afterwards?
    – Seth
    Jan 8 '18 at 19:32
















6














We have a custom image on 100's of PC's across the country that uses disk protection, and in order for our management platform software to update and work correctly, we had to create a junction to a drive that is not protected by disk protection.



The issue is this: When one of our PC's updates to 1709, it breaks those junctions we have set up, and we're then not able to access the PC to fix the other things 1709 breaks (such as overwriting our custom recovery environment, resetting default programs etc) because the program data folder is then bricked so our management software is unable to function correctly.



I was wondering if anyone else has encountered a similar issue and has found a fix, as we cannot spare the man hours to upgrade 100's of pc's to 1709 and then manually fix what gets broken.










share|improve this question




















  • 1




    In all likely hood it's an unsupported change. An example on how to fix it would be to deploy a script or use something like remote PowerShell. With such little information it's hard to tell what options you have available. As it is, don't let them update and prepare a 1709 image and deploy that instead?
    – Seth
    Jan 8 '18 at 19:05






  • 1




    In normal environments that honestly would probably be the best solution. However these are standalone PC's, that are used as kiosk machines. We update/maintain them via procedures that we setup on our management platform. So when we update them to 1709, and the junction breaks, we loose all management control via our platform and have to use a 3rd party remote app (similar to TeamViewer) to connect back and then manually fix the issues. If we're able to prevent/fix the junctions from breaking, then the rest is easy.
    – ztnd13
    Jan 8 '18 at 19:09










  • Was this junction in place with the last major update or have you switched to Win10 after that? Personally I'd expect it to break with major updates. It does look like moving ProgramData is actually supported, I'm assuming its on the same kind of drive? related.
    – Seth
    Jan 8 '18 at 19:20










  • Here's the scenario: PC running Windows 10 Pro x64, (version 1607 or 1703) C:programdataOursoftware junction in place, linked to D:ProgramdataOursoftware. When the PC updates to 1709, that junction gets broken.
    – ztnd13
    Jan 8 '18 at 19:28










  • So you didn't move the ProgramData folder as a whole, OK. What disk protection are you using? How does it work in conjunction with the update? Do you disable it beforehand and enable it afterwards?
    – Seth
    Jan 8 '18 at 19:32














6












6








6


0





We have a custom image on 100's of PC's across the country that uses disk protection, and in order for our management platform software to update and work correctly, we had to create a junction to a drive that is not protected by disk protection.



The issue is this: When one of our PC's updates to 1709, it breaks those junctions we have set up, and we're then not able to access the PC to fix the other things 1709 breaks (such as overwriting our custom recovery environment, resetting default programs etc) because the program data folder is then bricked so our management software is unable to function correctly.



I was wondering if anyone else has encountered a similar issue and has found a fix, as we cannot spare the man hours to upgrade 100's of pc's to 1709 and then manually fix what gets broken.










share|improve this question















We have a custom image on 100's of PC's across the country that uses disk protection, and in order for our management platform software to update and work correctly, we had to create a junction to a drive that is not protected by disk protection.



The issue is this: When one of our PC's updates to 1709, it breaks those junctions we have set up, and we're then not able to access the PC to fix the other things 1709 breaks (such as overwriting our custom recovery environment, resetting default programs etc) because the program data folder is then bricked so our management software is unable to function correctly.



I was wondering if anyone else has encountered a similar issue and has found a fix, as we cannot spare the man hours to upgrade 100's of pc's to 1709 and then manually fix what gets broken.







windows-10 windows-10-v1709






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 8 '18 at 19:25

























asked Jan 8 '18 at 18:59









ztnd13

596




596








  • 1




    In all likely hood it's an unsupported change. An example on how to fix it would be to deploy a script or use something like remote PowerShell. With such little information it's hard to tell what options you have available. As it is, don't let them update and prepare a 1709 image and deploy that instead?
    – Seth
    Jan 8 '18 at 19:05






  • 1




    In normal environments that honestly would probably be the best solution. However these are standalone PC's, that are used as kiosk machines. We update/maintain them via procedures that we setup on our management platform. So when we update them to 1709, and the junction breaks, we loose all management control via our platform and have to use a 3rd party remote app (similar to TeamViewer) to connect back and then manually fix the issues. If we're able to prevent/fix the junctions from breaking, then the rest is easy.
    – ztnd13
    Jan 8 '18 at 19:09










  • Was this junction in place with the last major update or have you switched to Win10 after that? Personally I'd expect it to break with major updates. It does look like moving ProgramData is actually supported, I'm assuming its on the same kind of drive? related.
    – Seth
    Jan 8 '18 at 19:20










  • Here's the scenario: PC running Windows 10 Pro x64, (version 1607 or 1703) C:programdataOursoftware junction in place, linked to D:ProgramdataOursoftware. When the PC updates to 1709, that junction gets broken.
    – ztnd13
    Jan 8 '18 at 19:28










  • So you didn't move the ProgramData folder as a whole, OK. What disk protection are you using? How does it work in conjunction with the update? Do you disable it beforehand and enable it afterwards?
    – Seth
    Jan 8 '18 at 19:32














  • 1




    In all likely hood it's an unsupported change. An example on how to fix it would be to deploy a script or use something like remote PowerShell. With such little information it's hard to tell what options you have available. As it is, don't let them update and prepare a 1709 image and deploy that instead?
    – Seth
    Jan 8 '18 at 19:05






  • 1




    In normal environments that honestly would probably be the best solution. However these are standalone PC's, that are used as kiosk machines. We update/maintain them via procedures that we setup on our management platform. So when we update them to 1709, and the junction breaks, we loose all management control via our platform and have to use a 3rd party remote app (similar to TeamViewer) to connect back and then manually fix the issues. If we're able to prevent/fix the junctions from breaking, then the rest is easy.
    – ztnd13
    Jan 8 '18 at 19:09










  • Was this junction in place with the last major update or have you switched to Win10 after that? Personally I'd expect it to break with major updates. It does look like moving ProgramData is actually supported, I'm assuming its on the same kind of drive? related.
    – Seth
    Jan 8 '18 at 19:20










  • Here's the scenario: PC running Windows 10 Pro x64, (version 1607 or 1703) C:programdataOursoftware junction in place, linked to D:ProgramdataOursoftware. When the PC updates to 1709, that junction gets broken.
    – ztnd13
    Jan 8 '18 at 19:28










  • So you didn't move the ProgramData folder as a whole, OK. What disk protection are you using? How does it work in conjunction with the update? Do you disable it beforehand and enable it afterwards?
    – Seth
    Jan 8 '18 at 19:32








1




1




In all likely hood it's an unsupported change. An example on how to fix it would be to deploy a script or use something like remote PowerShell. With such little information it's hard to tell what options you have available. As it is, don't let them update and prepare a 1709 image and deploy that instead?
– Seth
Jan 8 '18 at 19:05




In all likely hood it's an unsupported change. An example on how to fix it would be to deploy a script or use something like remote PowerShell. With such little information it's hard to tell what options you have available. As it is, don't let them update and prepare a 1709 image and deploy that instead?
– Seth
Jan 8 '18 at 19:05




1




1




In normal environments that honestly would probably be the best solution. However these are standalone PC's, that are used as kiosk machines. We update/maintain them via procedures that we setup on our management platform. So when we update them to 1709, and the junction breaks, we loose all management control via our platform and have to use a 3rd party remote app (similar to TeamViewer) to connect back and then manually fix the issues. If we're able to prevent/fix the junctions from breaking, then the rest is easy.
– ztnd13
Jan 8 '18 at 19:09




In normal environments that honestly would probably be the best solution. However these are standalone PC's, that are used as kiosk machines. We update/maintain them via procedures that we setup on our management platform. So when we update them to 1709, and the junction breaks, we loose all management control via our platform and have to use a 3rd party remote app (similar to TeamViewer) to connect back and then manually fix the issues. If we're able to prevent/fix the junctions from breaking, then the rest is easy.
– ztnd13
Jan 8 '18 at 19:09












Was this junction in place with the last major update or have you switched to Win10 after that? Personally I'd expect it to break with major updates. It does look like moving ProgramData is actually supported, I'm assuming its on the same kind of drive? related.
– Seth
Jan 8 '18 at 19:20




Was this junction in place with the last major update or have you switched to Win10 after that? Personally I'd expect it to break with major updates. It does look like moving ProgramData is actually supported, I'm assuming its on the same kind of drive? related.
– Seth
Jan 8 '18 at 19:20












Here's the scenario: PC running Windows 10 Pro x64, (version 1607 or 1703) C:programdataOursoftware junction in place, linked to D:ProgramdataOursoftware. When the PC updates to 1709, that junction gets broken.
– ztnd13
Jan 8 '18 at 19:28




Here's the scenario: PC running Windows 10 Pro x64, (version 1607 or 1703) C:programdataOursoftware junction in place, linked to D:ProgramdataOursoftware. When the PC updates to 1709, that junction gets broken.
– ztnd13
Jan 8 '18 at 19:28












So you didn't move the ProgramData folder as a whole, OK. What disk protection are you using? How does it work in conjunction with the update? Do you disable it beforehand and enable it afterwards?
– Seth
Jan 8 '18 at 19:32




So you didn't move the ProgramData folder as a whole, OK. What disk protection are you using? How does it work in conjunction with the update? Do you disable it beforehand and enable it afterwards?
– Seth
Jan 8 '18 at 19:32










1 Answer
1






active

oldest

votes


















0














Shouldn't a startup script that remakes the junction work to get your app back?



DeepFreeze works by taking a snapshot of the system and restoring it at each boot, but if you unfreeze the system, setup a startup script to remake the junction, and then refreeze, that should survive the upgrade.



To make a startup script just launch local Group Policy editor (or deploy out a startup GPO via Group Policy from a Domain Controller) via 'gpedit.msc' > Computer Configuration > Windows Settings > Scripts > Startup > Add > Create a .bat file on the local C: somewhere with the following contents:



mklink /j C:ProgramDatamyapp D:ProgramDatamyapp



Because it's a Computer startup script, it runs as the local SYSTEM account with full permissions, and will run before the logon screen ever appears.



Obviously you want the system to be un-frozen in DeepFreeze when you add this, and then re-freeze once the change is made.



Also, you can replace a recovery environment .wim file pretty easily with another startup script which does:
pushd serverpathtowinrefile



mkdir T:RecoveryWindowsRE
xcopy /h Winre.wim T:RecoveryWindowsRE



Note: If your recovery partition doesn't have a drive letter assigned, you can run a diskpart script to assign a drive letter first:
diskpart /s scriptname.txt



with scriptname.txt containing something like:
select disk 0
select partition 2
assign letter=R



However, this could be dangerous if not all your systems are partitioned the same, with partition 2 being the recovery partition.



Also, yes, installing version 1709 is literally installing an entirely new OS, like upgrading from Windows 8.1 to Windows 10. Less changes, but the process is the same. Honestly, the best thing to do is probably to reimage the systems using Microsoft Deployment Toolkit (MDT), which has a nice diskpart script step that will let you re-partition the drive however you want, and install any recovery environment image you want into it. MDT can be run remotely, and can be configured to backup any files, deploy the new image, and reboot the system afterwards into the new image, and then restore those files. After you're familiar with MDT, you may wonder why you need DeepFreeze in the first place. :)






share|improve this answer





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "3"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1283666%2fprogramdata-folder-junction-breaks-after-upgrade-to-1709%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    Shouldn't a startup script that remakes the junction work to get your app back?



    DeepFreeze works by taking a snapshot of the system and restoring it at each boot, but if you unfreeze the system, setup a startup script to remake the junction, and then refreeze, that should survive the upgrade.



    To make a startup script just launch local Group Policy editor (or deploy out a startup GPO via Group Policy from a Domain Controller) via 'gpedit.msc' > Computer Configuration > Windows Settings > Scripts > Startup > Add > Create a .bat file on the local C: somewhere with the following contents:



    mklink /j C:ProgramDatamyapp D:ProgramDatamyapp



    Because it's a Computer startup script, it runs as the local SYSTEM account with full permissions, and will run before the logon screen ever appears.



    Obviously you want the system to be un-frozen in DeepFreeze when you add this, and then re-freeze once the change is made.



    Also, you can replace a recovery environment .wim file pretty easily with another startup script which does:
    pushd serverpathtowinrefile



    mkdir T:RecoveryWindowsRE
    xcopy /h Winre.wim T:RecoveryWindowsRE



    Note: If your recovery partition doesn't have a drive letter assigned, you can run a diskpart script to assign a drive letter first:
    diskpart /s scriptname.txt



    with scriptname.txt containing something like:
    select disk 0
    select partition 2
    assign letter=R



    However, this could be dangerous if not all your systems are partitioned the same, with partition 2 being the recovery partition.



    Also, yes, installing version 1709 is literally installing an entirely new OS, like upgrading from Windows 8.1 to Windows 10. Less changes, but the process is the same. Honestly, the best thing to do is probably to reimage the systems using Microsoft Deployment Toolkit (MDT), which has a nice diskpart script step that will let you re-partition the drive however you want, and install any recovery environment image you want into it. MDT can be run remotely, and can be configured to backup any files, deploy the new image, and reboot the system afterwards into the new image, and then restore those files. After you're familiar with MDT, you may wonder why you need DeepFreeze in the first place. :)






    share|improve this answer


























      0














      Shouldn't a startup script that remakes the junction work to get your app back?



      DeepFreeze works by taking a snapshot of the system and restoring it at each boot, but if you unfreeze the system, setup a startup script to remake the junction, and then refreeze, that should survive the upgrade.



      To make a startup script just launch local Group Policy editor (or deploy out a startup GPO via Group Policy from a Domain Controller) via 'gpedit.msc' > Computer Configuration > Windows Settings > Scripts > Startup > Add > Create a .bat file on the local C: somewhere with the following contents:



      mklink /j C:ProgramDatamyapp D:ProgramDatamyapp



      Because it's a Computer startup script, it runs as the local SYSTEM account with full permissions, and will run before the logon screen ever appears.



      Obviously you want the system to be un-frozen in DeepFreeze when you add this, and then re-freeze once the change is made.



      Also, you can replace a recovery environment .wim file pretty easily with another startup script which does:
      pushd serverpathtowinrefile



      mkdir T:RecoveryWindowsRE
      xcopy /h Winre.wim T:RecoveryWindowsRE



      Note: If your recovery partition doesn't have a drive letter assigned, you can run a diskpart script to assign a drive letter first:
      diskpart /s scriptname.txt



      with scriptname.txt containing something like:
      select disk 0
      select partition 2
      assign letter=R



      However, this could be dangerous if not all your systems are partitioned the same, with partition 2 being the recovery partition.



      Also, yes, installing version 1709 is literally installing an entirely new OS, like upgrading from Windows 8.1 to Windows 10. Less changes, but the process is the same. Honestly, the best thing to do is probably to reimage the systems using Microsoft Deployment Toolkit (MDT), which has a nice diskpart script step that will let you re-partition the drive however you want, and install any recovery environment image you want into it. MDT can be run remotely, and can be configured to backup any files, deploy the new image, and reboot the system afterwards into the new image, and then restore those files. After you're familiar with MDT, you may wonder why you need DeepFreeze in the first place. :)






      share|improve this answer
























        0












        0








        0






        Shouldn't a startup script that remakes the junction work to get your app back?



        DeepFreeze works by taking a snapshot of the system and restoring it at each boot, but if you unfreeze the system, setup a startup script to remake the junction, and then refreeze, that should survive the upgrade.



        To make a startup script just launch local Group Policy editor (or deploy out a startup GPO via Group Policy from a Domain Controller) via 'gpedit.msc' > Computer Configuration > Windows Settings > Scripts > Startup > Add > Create a .bat file on the local C: somewhere with the following contents:



        mklink /j C:ProgramDatamyapp D:ProgramDatamyapp



        Because it's a Computer startup script, it runs as the local SYSTEM account with full permissions, and will run before the logon screen ever appears.



        Obviously you want the system to be un-frozen in DeepFreeze when you add this, and then re-freeze once the change is made.



        Also, you can replace a recovery environment .wim file pretty easily with another startup script which does:
        pushd serverpathtowinrefile



        mkdir T:RecoveryWindowsRE
        xcopy /h Winre.wim T:RecoveryWindowsRE



        Note: If your recovery partition doesn't have a drive letter assigned, you can run a diskpart script to assign a drive letter first:
        diskpart /s scriptname.txt



        with scriptname.txt containing something like:
        select disk 0
        select partition 2
        assign letter=R



        However, this could be dangerous if not all your systems are partitioned the same, with partition 2 being the recovery partition.



        Also, yes, installing version 1709 is literally installing an entirely new OS, like upgrading from Windows 8.1 to Windows 10. Less changes, but the process is the same. Honestly, the best thing to do is probably to reimage the systems using Microsoft Deployment Toolkit (MDT), which has a nice diskpart script step that will let you re-partition the drive however you want, and install any recovery environment image you want into it. MDT can be run remotely, and can be configured to backup any files, deploy the new image, and reboot the system afterwards into the new image, and then restore those files. After you're familiar with MDT, you may wonder why you need DeepFreeze in the first place. :)






        share|improve this answer












        Shouldn't a startup script that remakes the junction work to get your app back?



        DeepFreeze works by taking a snapshot of the system and restoring it at each boot, but if you unfreeze the system, setup a startup script to remake the junction, and then refreeze, that should survive the upgrade.



        To make a startup script just launch local Group Policy editor (or deploy out a startup GPO via Group Policy from a Domain Controller) via 'gpedit.msc' > Computer Configuration > Windows Settings > Scripts > Startup > Add > Create a .bat file on the local C: somewhere with the following contents:



        mklink /j C:ProgramDatamyapp D:ProgramDatamyapp



        Because it's a Computer startup script, it runs as the local SYSTEM account with full permissions, and will run before the logon screen ever appears.



        Obviously you want the system to be un-frozen in DeepFreeze when you add this, and then re-freeze once the change is made.



        Also, you can replace a recovery environment .wim file pretty easily with another startup script which does:
        pushd serverpathtowinrefile



        mkdir T:RecoveryWindowsRE
        xcopy /h Winre.wim T:RecoveryWindowsRE



        Note: If your recovery partition doesn't have a drive letter assigned, you can run a diskpart script to assign a drive letter first:
        diskpart /s scriptname.txt



        with scriptname.txt containing something like:
        select disk 0
        select partition 2
        assign letter=R



        However, this could be dangerous if not all your systems are partitioned the same, with partition 2 being the recovery partition.



        Also, yes, installing version 1709 is literally installing an entirely new OS, like upgrading from Windows 8.1 to Windows 10. Less changes, but the process is the same. Honestly, the best thing to do is probably to reimage the systems using Microsoft Deployment Toolkit (MDT), which has a nice diskpart script step that will let you re-partition the drive however you want, and install any recovery environment image you want into it. MDT can be run remotely, and can be configured to backup any files, deploy the new image, and reboot the system afterwards into the new image, and then restore those files. After you're familiar with MDT, you may wonder why you need DeepFreeze in the first place. :)







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 12 '18 at 5:29









        Nate Cartwright

        362




        362






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Super User!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1283666%2fprogramdata-folder-junction-breaks-after-upgrade-to-1709%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            RAC Tourist Trophy