Last week I was working with a customer on a problem with software installations using Active Directory Group Policy Objects (GPOs). We had the GPO installs working great for months. The installation files for the software had to be migrated from one of the cluster servers to another cluster during system upgrades. During this process a Dfs tree was setup for files shares in the organization.
The plan was to use the Dfs path for the software installation source files from this point on. This would be beneficial because when the software installation source path changes the GPO has to be modified to use the new path. This is done by creating a new software installation package within the GPO and deleting the old installation package using the old source path within the GPO. This may not e a big deal if there are only a handful of applications delivered through the GPO but when you get into higher numbers it can become a real pain.
When I got called in to assist with this issue, at first glance it looked as if there was possibly something wrong with the Distributed file system (Dfs), since the GPO wouldn’t install managed software onto the workstations using the Dfs share to the source files.
The workstation showed Event ID in the Application log of 102, 108, 303 from the ‘Application Management’ source.
The resolution is toward the bottom if you want to skip all the details.
Here are the steps I took to get to the bottom of the issue:
1. Eliminated the source files and the GPO security as the issue – I setup a share on a file server, copied the source files over, created an installation package and tested.
2. Eliminated Dfs as the source of the problem. – I created a Dfs link to point to the share I created in step 1, created a new installation package… worked fine.
3. Eliminated the active cluster node (security/availability) as a source of the issue. I created a software install package using the server node name of active node in the cluster… worked fine.
At this point it was obvious that it was an issue with the cluster service. But where to go from here was tricky. I could access the installation files through the cluster share no problem. I tried it as an admin and a regular network user… I could run the install manually using the same source files and path the GPO where setup to use.
I checked the event logs on the server again, and ran some diagnostic utilities on the server, got some errors on DNS which didn’t apply. I triple checked the permissions on the share and folders. I even granted the test machine account explicit full control permissions to the share… but nothing. Next I created a new network name cluster resource and setup a new share to the install files. Still didn’t work.
This is what it came down to. RESOLUTION
There were no computer accounts in Active Directory for the network name of the resource group. For example the virtual name of the cluster server could be \\filecluster1\software\ , while the actual names of the physical server nodes could be \\file1node1 and \\file1node2 “. So while the name could be accessed manually, it wouldn’t work to apply software through a GPO.
What happened was that the cluster service domain account was a member of the “Domain Users” group and not a member of the “Domain Admins” group. By default “Domain Users” have rights to add computer account objects to Active Directory a total of 10 times. This limit was obviously reached before the cluster services could add the “Network Name” resources to Active Directory as a computer objects. This caused the Kerberos authentication not to work properly when the GPO & machine attempted to access shares from the clustered Network Name resource which requires the network name resource have a computer object in AD.
In order to register the Network Name resource in AD the Network Name resource must be brought offline and the command ‘cluster res “network name resource” /priv requirekerberos=1:dword’ be run as a domain admin at the command prompt on the active cluster node. This creates the required computer object in AD for the resource and fixes the Kerberos authentication problems. I would open a command prompt type the command, then bring the network name offline, press enter to execute the command in the command window, and then bring the resource back online. It only saves 30-60 seconds of downtime, but that can mean a few phone calls if it’s done at the wrong time.
Microsoft KB 302389 provides further details along with KB 235529 which also provides a work-around for this issue.
Other articles I used in the researched are: Microsoft KB 278472, KB 241452, KB 305293, and KB 257932.
Disclaimer: Use this information at you own risk. This information is as is. No guarantees or warranties are implied. That goes for all of the information contained on this site.