ProgramData folder junction breaks after upgrade to 1709
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
|
show 4 more comments
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
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 movingProgramData
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
|
show 4 more comments
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
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
windows-10 windows-10-v1709
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 movingProgramData
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
|
show 4 more comments
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 movingProgramData
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
|
show 4 more comments
1 Answer
1
active
oldest
votes
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. :)
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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. :)
add a comment |
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. :)
add a comment |
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. :)
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. :)
answered Dec 12 '18 at 5:29
Nate Cartwright
362
362
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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