|
|
We are a Novell shop running XP Pro SP2 clients and WSUS 3. We direct
our My Documents and Favorites folders to a mapped drive so that users
can access their data regardless of machine. When a standand user
receives an MSI based patch via Automatic Updates/WSUS, the update
will fail because the System account cannot see mapped drives. The
only workaround I could think of other than disabling folder
redirection is to run a Subst.exe command in the System context during
every login to create an alias that points the non-accessible mapped
drive to the C: drive. Are there any other cleaner solutions to this
issue or is using Subst the best option?
Thanks
|
|
<jdbst56[ at ]gmail.com> wrote in message
news:b265a93d-56b4-45ac-a983-f5085a714dac[ at ]z28g2000prd.googlegroups.com...
[Quoted Text] > When a standand user
> receives an MSI based patch via Automatic Updates/WSUS, the update
> will fail because the System account cannot see mapped drives.
Unless you've installed parts of the OS or Programs to a network mapped
drive, this should have no issue at all.
ALL files downloaded by the WUA are written to
%windir%\SoftwareDistribution\Download, and, generally, Windows Installer
creates a temp file on the LOCAL drive with the most free space. To my
knowledge, there's nothing in this process that would have any interest in
the "My Documents" or the "Favorites" folders. Furthermore, I am not aware
of any component in this entire process that would have need, or interest,
in using a network mapped drive.
> Are there any other cleaner solutions to this
> issue or is using Subst the best option?
Well before we start talking about solutions, or conclusions, let's first
look at the observed behavior.
What *exactly* is occurring that makes you believe an installation is
failing, or that an installation is failing because of access issues to a
network resource?
--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
|
|
Hi, the particular patch in question KB954326 (Visio patch) uses
Windows Installer MSI for its install routine. Most MSI installers
will check for the presence of the My Documents directory during
setup. In our case, since the folder is pointed to a network location
that is not visible to the System account, the install fails due to
the fact that the directory cannot be found. This yields a 1327 MSI
error in the event log "invalid drive N:\" with N:\ being where our My
Documents folder is redirected.
See this thread
http://groups.google.com/group/microsoft.public.sms.misc/browse_thread/thread/4125398d59b06eb6?hl=en&ie=UTF-8&q=msi+1327
for more detail on the problem.
Surprisingly, the issue doesn't usually occur on Microsoft generated
MSIs but for some reason it does for this one. I would assume that
Microsoft removes the requirement for checking for this directory if
it isn't really needed. In most cases, the installer doesn't have to
write anything to the My Documents folder, but rather is checked for
existance by default in the installation routine. If the patch was
one we were pushing out and not WSUS, one option that we have used in
the past is to edit the MSI database file with Orca editor and remove
the rows in the database that check for My Documents. Obviously this
isn't an option for patches deployed via WSUS.
Thanks
|
|
<jdbst56[ at ]gmail.com> wrote in message
news:4e791bfa-891c-40d5-af28-73e41d9820b0[ at ]a17g2000prm.googlegroups.com...
[Quoted Text] > Hi, the particular patch in question KB954326 (Visio patch) uses
> Windows Installer MSI for its install routine. Most MSI installers
> will check for the presence of the My Documents directory during
> setup. In our case, since the folder is pointed to a network location
> that is not visible to the System account, the install fails due to
> the fact that the directory cannot be found. This yields a 1327 MSI
> error in the event log "invalid drive N:\" with N:\ being where our My
> Documents folder is redirected.
There are organizations the world over that have had "My Documents"
redirected to a server-based share since the capability first became
available in Windows 2000. I ran My Documents redirected to an SBS2003
server for years, with never a hint of problems. At my work environment, for
the past year, I redirected My Documents to a network server, and never
experienced any issues installing updates.
What you're doing is neither new, nor unique, and truly, I'm hard pressed to
believe that such a common configuration would break an update.
> See this thread
> http://groups.google.com/group/microsoft.public.sms.misc/browse_thread/thread/4125398d59b06eb6?hl=en&ie=UTF-8&q=msi+1327
> for more detail on the problem.
This thread is FOUR years old, and involves an environment on a Windows NT
4.0 domain using SMS v2.0. I highly doubt it's relevant. In fact, I did a
search on "MSI error 1324" as the post suggested, and every single hit that
came back was a pre-WI v3 post, running on Netware or NT4 systems.
I did some additional search on "MSI error 1327", and found essentially the
same results.... old threads.
However I did get one clue from those threads: Your issue may not be that
"My Documents" is redirected, per se, but that you've redirected it to a
MAPPED DRIVE, rather than redirecting it to a =UNC= share. The correct way
to redirect My Documents is via UNC pathnames. Change the redirection
configuration of My Documents, and you may find the update now works.
Essentially the problem is this: The =N:= drive only exists when a user is
logged on. When the WUA attempts to find this drive during a scheduled
installation (with the user logged off), the drive doesn't exist.
Your other alternative is to install the update interactively, while a user
is logged on and the N: drive does exist.
--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
|
|
[Quoted Text] > However I did get one clue from those threads: Your issue may not be that
> "My Documents" is redirected, per se, but that you've redirected it to a
> MAPPED DRIVE, rather than redirecting it to a =UNC= share. The correct way
> to redirect My Documents is via UNC pathnames. Change the redirection
> configuration of My Documents, and you may find the update now works.
>
> Essentially the problem is this: The =N:= drive only exists when a user is
> logged on. When the WUA attempts to find this drive during a scheduled
> installation (with the user logged off), the drive doesn't exist.
>
> Your other alternative is to install the update interactively, while a user
> is logged on and the N: drive does exist.
You are correct in that we are using a mapped drive and not UNC path.
We are a Novell shop. We redirect to a mapped drive which I mentioned
in my original message. Unfortunately I cannot change that. However
you are not correct in when the problem occurs. The issue occurs
regardless of if a user is logged on interactively or not because the
System account is in use and the security of XP does not permit the
System account to have access to mapped drives http://www.ithowto.com/Articles/ZWXPDrive.htm
In terms of using UNC paths, we have multiple locations and the N:
drive mapping is to the users' home drives which can reside on a
number of different servers. N: drive can differ per user depending
which server their home directory is located.
If you do a google search for "1327 folder redirection" you'll find
many results even recent ones for issues with MSI installations
failing due to the My Documents folder not being available.
|
|
joshbilsky[ at ]gmail.com wrote:
[Quoted Text] > You are correct in that we are using a mapped drive and not UNC path.
> We are a Novell shop. We redirect to a mapped drive which I mentioned
> in my original message. Unfortunately I cannot change that.
As this isn't supported, you may have to live with any problems it causes.
> However
> you are not correct in when the problem occurs. The issue occurs
> regardless of if a user is logged on interactively or not because the
> System account is in use and the security of XP does not permit the
> System account to have access to mapped drives [...]
If no user is logged on (and in most cases even if a user *is* logged on) WSUS
updates should be running in system context. If it is having a problem due to
redirected folders, this suggests that the redirection is being applied to the
system context, which is abnormal. Folder redirection is normally applied via
group policy, and applies only to domain users.
So: how are the folders being redirected?
At a guess the system context would look up the Default User registry key for
folder redirection, so if the folder redirection has somehow wound up affecting
Default User that may be your problem.
Harry.
|
|
I have seen this problem in Novell environments when "folder redirection"
was done via registry settings (or custom ADM template) that were pushed via
a ZENworks application (or ZENworks group policy object) that had been
mistakenly associated with the ZENworks workstation object (causing the
folder redirection settings to be applied to the default user profile).
"Harry Johnston [MVP]" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:uJm0ZUqSJHA.1560[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] > joshbilsky[ at ]gmail.com wrote:
> At a guess the system context would look up the Default User registry key
> for folder redirection, so if the folder redirection has somehow wound up
> affecting Default User that may be your problem.
|
|
|
|
|