The chain reaction started when a customer’s line of business application doesn’t work with UNCs

A customer (via their customer liaison) reported that they use Folder Redirection to put various folders on a network share, but they discovered that one of their line of business applications doesn't work when the application's Data Directory is set to a UNC. The customer is working with the vendor to address the problem, but in the meantime, they need to deploy a temporary fix. What they've found is that they can change the Data Directory for the application in the registry and point it to a local directory.

This works, except that some other unknown line of business application is going in and resetting the registry key back to the network location.

One thing they could try is ask the vendor of the original line of business application if there is a Group Policy that they can use to force the Data Directory to be a specific location. Standard group policy registry keys are kept in a registry key that grants write access only to administrators, which means that the rogue line of business application will not be able to write to it.

Our suspicion was that this avenue of exploration was likely to lead to a dead end, so we had to try some other ideas.

Another idea is to use a Group Policy to deploy a script that sets the registry key for the Data Directory to the local directory. (It appears that there's also a special type of Group Policy setting just for registry entries.) The customer had thought of this, but realized that the rogue line of business application will eventually come along and stomp on the value, so any relief would be short-lived.

To work around this, the customer could mark the registry entry as Process Even If The Group Policy Objects Have Not Changed. The registry key will be set back to the policy value each time Group Policy refreshes.

This is still not great, because it means that when the rogue line of business appliation changes the registry key, it'll take up to 90 or 120 minutes for the policy to refresh and reset the value. The customer could change their refresh interval to lower the size of this window, but it increases the cost of group policy processing across their entire network.

What they can do is set a security audit on the registry key that triggers when a write to the key occurs. That will generate an entry in the security event log which will identify the program that is writing to the key. That will at least let them identify the rogue line of business application, and then they can work with the vendor of that other rogue program to see if they can disable the rogue behavior.¹

If they cannot disable the rogue behavior, then as a final desperation measure, they could set the key value to the desired value, and then make the registry key read-only. That way, when the rogue line of business application tries to reset the value, it will fail. This does assume two things:

  1. The original program can cope with one of its configuration registry keys being read-only.
  2. The rogue program doesn't respond to the inability to reset the key by going double-rogue.

¹ Given that the registry key in question is custom to the original line of business application, it's possible that the rogue line of business that is resetting the registry key comes from the same vendor as the original program! But maybe if they're lucky, it's some custom in-house program that they can modify.

Comments (10)
  1. Joshua says:

    I’ve seen this. You may be in the following bad case: They have a subcomponent as a library that must have a registry key pointing to its workspace, but the main application can’t handle it being repointed and so always sets the value in the registry for the subcomponent.

    If not this case, RegNotifyChangeEx is your friend.

  2. Couldn’t they just mount the “bad” path over the default data folder?

    1. Alex Cohn says:

      On the face of it, they were not looking for simple solutions

    2. Ian Yates says:

      Yeah, I’d be tempted to try a symlink. They’re a very handy way of pushing data around for apps that insist on C:. I used them heavily on an old laptop that had 2x HDDs and I’d put a lot of stuff on C:. Rather than reinstall apps, etc I just made symlinks for c:\program files\blah to d:\program files\blah. I don’t think I ever ran into any problems (that I saw at least) :)

      I’ve done the same for a VM running a really old read-only copy of a LOB app that I occasionally need to look at. It’s data sits on my machine and the VM has a symlink of c:\app\data pointing to \\workstation\oldLOBAppData share. That old app is none the wiser.

    3. Presumably, they want the folder redirection to remain in place – you don’t generally want to redesign your network just because one application is misbehaving. Or at least that would be a last resort.

      The fact that the application’s data directory needs to be local (which you might indeed solve with a symlink or junction point) doesn’t seem to be a problem for them, it’s just that they’re having trouble telling the application to ignore the folder redirection.

  3. cheong00 says:

    Btw, will adding “deny write” access to “INTERACTIVE user” work? (Assuming their LOB application is WinForm client and not Windows Service process, because if it’s service, you’d create a domain account to run the service and just deny write access of that registry key to that account)

  4. Scarlet Manuka says:

    I was rather expecting through the whole article that the application that was going in and resetting the registry key was going to be the same one that the key was for. If the registry key is for that application’s data directory, surely that application is the most likely one to be mucking around with it.

    I suppose it could also be one program acting as a kind of supervisor and making sure everyone has the correct settings, in which case it is probably, as Raymond suggested, a related program from the same vendor.

    The security audit sounds like a good idea, at the very least to see whether the problem is indeed coming from inside the house.

  5. Ray Koopa says:

    That reminds me of another case where I wanted to set a whole registry folder to read-only; the ShellIconOverlayIdentifiers one. Windows 10 just loves to put 3 or 4 subkeys in there for SkyDrive, then another 3 or 4 for OneDrive. That pushed my important TFS overlays so far back to the list, the overlays were gone almost every time Win10 did some updates.

    I couldn’t really prevent the updates from smearing stuff in there (also not thinking that would’ve been a good idea), and eventually just made sure to keep my overlays alphabetically at the top (which was a little annoying since the SkyDrive ones began with a space character)…

    1. Zarat says:

      Yup, the tight limit of UI overlays together with every program supporting it trying to get top places is really annoying. When there are such strict resource limits there should be separate UI where the user can select the UI overlays he wants among installed overlays, instead of allowing random programs to mess up things.

  6. alegr1 says:

    I suspect it the case of an application or service running under token which doesn’t have access to network locations, and then it resets the location to default because the configured location is not accessible. Or the location is temporarily inaccessible because of network dropout. Same mistake as Windows Desktop Cleanup task does (does Windows 8/10 still have that abomination?).

Comments are closed.

Skip to main content