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.

|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:\programdata\Oursoftware junction in place, linked to D:\Programdata\Oursoftware. 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
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:\ProgramData\myapp D:\ProgramData\myapp

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 \server\path\to\winrefile\

mkdir T:\Recovery\WindowsRE xcopy /h Winre.wim T:\Recovery\WindowsRE

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. :)

|improve this answer

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.