User-assigned Group Policy software installation and redirected User Shell Folders

[Steph Jones]

Hi all,

Got a problem with our deployment, and wondered if anyone else has had
to overcome this scenario? This actually is on Windows 2003 Server,
but could not see a specialist group for W2K Group Policy.

Our image has User Shell Folders\AppData redirected from the default
of C:\Documents and Settings\<username>\Application Data, to H:
\Application Data. This approach has been in use for years and so so
much of the desktop image, applications, etc. use it happily.

This seems to cause us a problem with user-assigned applications
through GPSI policies. We are not setting these applications to auto-
install, so we can achieve the useful 'placeholder icon' in the Start
Menu until a user decides they want that app, clicks on the the icon,
it calls the MSI to install, and runs automatically.

This works fine on XP when the User Shell Folders have no redirection,
however, with AppData redirected, the assignment fails:

Event Type: Error
Event Source: Application Management
Event ID: 101
User: NT AUTHORITY\SYSTEM
Description:
The assignment of application <appname> from policy <gpo policy>
failed. The error was : Fatal error during installation.

Event Type: Error
Event Source: Userenv
Event ID: 1000
User: NT AUTHORITY\SYSTEM
Description:
The Group Policy client-side extension Application Management was
passed flags (1) and returned a failure status code of (1603).

I've spent a long while looking at error 1603 (and 0x643 in userenv)
to find its a very generic error code.

If I restore the User Shell Folders\AppData key back to the default (C:
\Documents and Settings...) then the assignment is successful.
Redirect it again to H: and it fails.

The key difference I can see is this...

Windows Installer and GP Application Management run on the local
workstation under SYSTEM. When you use the default AppData (C:
\Documents and Settings...) the permissions on that user profile
folders are workstation\Administrators, workstation\SYSTEM and domain
\username.

The permissions for the network hosted home folder (H:\username
\Application Data...) are domain\Administrators and domain\username.
As this is hosted on a SAN, we are unable to add workstation\SYSTEM
from the local workstation, so I presume (although I may be wrong!)
that this is the underlying problem - and thus when Application
Management and Windows Installer attempt to do anything, they do it
under workstation\SYSTEM which fails as soon as it tries to do any
read/writes to the redirected Application Data folder due to lack of
appropriate permissions - I've tried tests with everyone,
authenticated users, domain computers just in case but no joy.

Is this theory correct, and more importantly, is there anyway around
it or is such behaviour completely fixed?

Ta in advance,
Steph

 

[Florian Frommherz [MVP]]

Howdie!

Hi all,

Got a problem with our deployment, and wondered if anyone else has had
to overcome this scenario? This actually is on Windows 2003 Server,
but could not see a specialist group for W2K Group Policy.

There's a group called microsoft.public.windows.group_policy that would
also fit - but never mind.

Our image has User Shell Folders\AppData redirected from the default
of C:\Documents and Settings\<username>\Application Data, to H:
\Application Data. This approach has been in use for years and so so
much of the desktop image, applications, etc. use it happily.

Try two things:

- don't redirect it to "H:\" but instead to the UNC path of the share
\\server\\share\%username%\Application Data
- Assign "Authenticated Users" necessary rights on that folder (Full
Control for short testing could be okay).

Does that work?

cheers,

Florian

 

[Steph Jones]

Hi Florian,

Using the UNC path does allow the assignment to successfully push -
but still a problem on the app. The placeholder 'icon' is lost,
although the actual shortcut to drive the app is there - I think this
is due to still having a problem writing to the redirected Application
Data folder. If I compare the behaviour with an image with the AppData
still on the C:\Document and Settings\... profile, I notice that a
folder called Installer is created, with the <guid> underneath for the
assigned app, and then the newicon.exe file that drives the icon for
the placeholder shortcut.

If I try to run the MSI app, it gets so far then fails with not being
able to access one of the cabs (all the MSI's are tested ok) - I
presume this is because the MSI has tried to expand data1.cab that is
encapsulated inside the MSI into the AppData folder, then read it -
but of course its not been able to write the file, and thus fails.

I've tried Authenticated Users and Domain Computers F/C on the home
folder share, but not having any joy!

Steph