"Error 1327". Any way to bypass the USER SHELL FOLDERS check?
"Error 1327". Any way to bypass the USER SHELL FOLDERS check?
Hi all,
This is my problem.
We have a rather convoluted and complicated network set up currently as we are mid-migration from Novell to AD.
Our workstations currently authenticate against both Novell (via Netware client v3.92), and Active Directory (i.e. computers are members of the domain).
We are trying to use the AD Group Policy Software Installation to push some MSI's to
install at logon time, but we have this problem:
In USER SHELL FOLDERS, amongst others, we hard redirect DESKTOP to a network drive (G:\) - driven by Novell.
The big problem is that Novell is a little sluggish at sorting out the drive mapping, and in the time its 'thinking about it', AD has already piped up to install the MSI.
The MSI I'm building is a simple one to add some shortcuts on the desktop and start menu, but it fails on the classic "Error 1327. Invalid Drive G:\" because at the point of installing, the G: drive isn't available.
Even if I modify my MSI to only install shortcuts to non-redirected paths (i.e. C:\%USERPROFILE%) and which are definately available, the MSI still fails with this error because I believe the standard behaviour of the Windows Installer is to check HKCU...USER SHELL FOLDERS.
Is there anyway of bypassing this check within the MSI?? So, it ignores whatever re-directed registry keys are in HKCU...USER SHELL FOLDERS??? This way, I could still get the MSI to place shortcuts where I want them. Or can I modify the MSI to 'fool' it into thinking the G: drive is available even if it doesn't use it?
Any ideas??
Appreciate that my environment is really the problem, but this can't change for a while until Novell is totally out of the picture.
Stephen
Hi all,
This is my problem.
We have a rather convoluted and complicated network set up currently as we are mid-migration from Novell to AD.
Our workstations currently authenticate against both Novell (via Netware client v3.92), and Active Directory (i.e. computers are members of the domain).
We are trying to use the AD Group Policy Software Installation to push some MSI's to
install at logon time, but we have this problem:
In USER SHELL FOLDERS, amongst others, we hard redirect DESKTOP to a network drive (G:\) - driven by Novell.
The big problem is that Novell is a little sluggish at sorting out the drive mapping, and in the time its 'thinking about it', AD has already piped up to install the MSI.
The MSI I'm building is a simple one to add some shortcuts on the desktop and start menu, but it fails on the classic "Error 1327. Invalid Drive G:\" because at the point of installing, the G: drive isn't available.
Even if I modify my MSI to only install shortcuts to non-redirected paths (i.e. C:\%USERPROFILE%) and which are definately available, the MSI still fails with this error because I believe the standard behaviour of the Windows Installer is to check HKCU...USER SHELL FOLDERS.
Is there anyway of bypassing this check within the MSI?? So, it ignores whatever re-directed registry keys are in HKCU...USER SHELL FOLDERS??? This way, I could still get the MSI to place shortcuts where I want them. Or can I modify the MSI to 'fool' it into thinking the G: drive is available even if it doesn't use it?
Any ideas??
Appreciate that my environment is really the problem, but this can't change for a while until Novell is totally out of the picture.
Stephen
0 Comments
[ + ] Show comments
Answers (0)
Please log in to answer
Be the first to answer this question
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.