3

I have a persistent issue with a number of our Windows desktop systems where we see various MSI packages throw up error 1606 (and 1314, in the MSI log), which is a permission issue, when attempting to be installed. The location is almost always that of a user's documents, pictures or some other folder in this hierarchy - but this location does exist and it is very possible to access it (as evidenced by logfiles that can be generated and stored in said locations).

For a while I've been thinking it is because we set users' directories to UNC paths, because changing them to drive letters seems to fix the issue. However, there are instances where the UNC path hasn't seemed to cause on issue on unrelated machines with identical settings (SCCM client settings, same applied GPOs, same permissions etc) to those that do have the issues.

I've searched a lot on technet, autodesk forums and been in contact with the company that supports one of the packages we use, but nobody seems to have been able to help so far. The commonly given answer is to check the paths in the User Shell Folders key in the registry, but these are deliberately set to UNC paths.

FYI, we use UEV to virtualise a user's profile. They log on and then the following mappings occur:

  • User files for their %homeshare% are stored on a network share, under \fileserver\home$\username\ (e.g. Documents, Desktop, etc.)
  • User settings for %appdata% are stored on a network share, under \fileserver\setting$\username\

Each user has access to their own shares on the paths above and have full permissions over their area.

One package, for example, is set to install per-user at logon. As is typical for this issue, we then get an error saying that the desktop folder can't be accessed, when it can clearly be. However, running as administrator has, sometimes, worked - but again, this is a per-user package, so it really has to be run for the user logged in. I'm not even sure that the folders that throw an error are even used; so is this just a poorly configured MSI?

Registry settings are as below, for a standard machine:

enter image description hereenter image description hereenter image description here

Here are some examples of applications we use where I've seen have the errors:

AutoCAD 2014:

Error 1606 pops up when a user (some users, not all it seems) try to run AutoCAD for the first time. If an administrator (local and domain) tries to launch it, everything runs fine and it appears that settings are stored locally, rather than on their network share storage area for their settings. Sometimes. But if a regular user tries to run it, the message appears that it can't access a folder.

Autograph 3.20:

Error 1606 pops up when trying to install AutoCAD as a domain user. Eventually the installation fails, because it can't access /SendTo or /Documents

Examples from the msiexec log:

MSI (c) (40:28) [15:55:12:744]: Note: 1: 1314 2: \\fileservc\settings$\otb\Microsoft\Windows\SendTo \
MSI (c) (40:28) [15:55:12:744]: Note: 1: 1606 2: \\fileservc\settings$\otb\Microsoft\Windows\SendTo \
Error 1606.Could not access network location \\fileservc\settings$\otb\Microsoft\Windows\SendTo \.
MSI (c) (40:28) [15:57:45:230]: Product: Autograph 3.20 -- Error 1606.Could not access network location \\fileservc\settings$\otb\Microsoft\Windows\SendTo \.

Cloud Drive Mapper:

This runs for each user when they log on, to map their drive. This involves msiexec, which for most users, results in error 1606 when trying to map their desktop (whether this is what is intended or not isn't the point, its more that the logged on user can access a location that the setup can't seem to) Examples from the msiexec log:

MSI (c) (70:04) [10:00:49:185]: Product: Cloud Drive Mapper -- Error 1606. Could not access network location \\fileservc\home$\OTB\Desktop\.

MSI (c) (70:04) [10:00:49:185]: Note: 1: 1314 2: \\fileservc\home$\OTB\Desktop\
MSI (c) (70:04) [10:00:49:185]: Note: 1: 1606 2: \\fileservc\home$\OTB\Desktop\
MSI (c) (70:04) [10:00:49:185]: Note: 1: 2262 2: Error 3: -2147287038

I thought perhaps it was an issue with the local host running msiexec as "system", but the error logs seem to indicate that it is running as the logged on account:

enter image description here

Additionally, the file server shows no error logs in event viewer - I tried to add auditing on a test user's shared folder and checking for failure on all policies under Local Policies/Audit Policy/. Nothing shows up. The only place errors are shown is on msiexec on a local machine.

I've also tried trusting the test machine for delegation to the file server, and changing the file server's security settings to add the test computer account's with full access just to cover all bases. No difference.

Rob Moir
  • 31,884
  • 6
  • 58
  • 89
Trevelyan
  • 81
  • 1
  • 5
  • Could you please try capturing and sharing few [ProcMon](https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) traces while trying to install these apps with us? – Tomas Dabasinskas Apr 05 '16 at 08:11
  • Here we go - http://expirebox.com/download/17158712c01bc78913933f7c80fdb931.html - So basically on one host, it succeeds to install this exe-wrapped-MSI file for digital microscopes. On another host, it fails. A third file is included for halfFail because at one point, hitting "retry" would make it proceed through to the next part of installation, but I am not exaggerating when I say that it is sporadic. I have ended most processes on the systems including disabling Offline Files, but still the inconsistency. If the logs need less filtering, let me know. Cheers! – Trevelyan Apr 05 '16 at 10:27
  • And here is a difference between two msi logs for a drive mapping piece of software, both attempting an uninstall https://www.diffchecker.com/zr3dhg50 – Trevelyan Apr 05 '16 at 10:33
  • It seems that the problem is that (and I don't know why) MSIEXEC stores it's cache/configuration/logs not under C:\Windows\Installer, but under %APPDATA%\Microsoft\Installer, which in your case is \\fileservc\settings$\otb\Microsoft\Installer. This means that one computer might be deleting these files (lines 534-545 on the left side of the diff), while another computer already done that (lines 1086-1088 on the right). This results in installation inconsistencies and likely the setup failures. – Tomas Dabasinskas Apr 05 '16 at 10:54
  • Sounded interesting, but the following shows applications sharing the same directories. https://www.diffchecker.com/lenddzal – Trevelyan Apr 05 '16 at 12:42
  • Tomas - I'm coming back to this and wondering if this is the issue and worth exploring further. But, as you say, I have no idea why it would store anything under the user's folder. What about entries that the Windows Installer puts into registry? The frustration is that there are no group policy differences between machines/users and nor are there any registry differences for the shell folders which is the usual suspect it seems. – Trevelyan May 20 '16 at 10:21
  • @Trevelyan did you ever manage to resolve this issue? I'm struggling with something similar now – MarkNS Apr 28 '20 at 10:16

0 Answers0