Group Policy software installation fails - windows installer error %1612

ahahum
ahahum used Ask the Experts™
on
Greetings!

I have a strange issue going on in my environment that has me beating my head against the wall.

Windows 2003 Domain - 3 2003 Domain controllers running DNS & WINS.
DFS Root - 3 domain controllers all as root replicas
DFS Target - 1 2003 Windows server hosting all software to be deployed
Affected Clients - any OS I've deployed software to - XP, 7, 2003, 2008

Software installation has worked fine, but stopped working abruptly in the past week or so.

The error in the logs of the clients who fail to install the software is event ID 105: the install of %software% from policy %GPO-NAME% failed - the error was %1612.  This indicates that the share is unavailable for whatever reason.  I can login to the machine and access the share fine.  We also have other DFS targets that appear to be working correctly for our User home directories and other shared files for the orginization.

I do not think it is permissions on the shares/ntfs, but as a troubleshooting step I added everyone full control to the share and NTFS permissions.  This caused no change in the problem.

I think the problem is DFS related because I created a new test GPO and pushed some software from it using the straight UNC path to the share on the server (\\server\sjare) and the software installed correctly.

Does anyone have any ideas for me to start looking at?  I am majorly confused because the DFS environment seems to be working correctly since we have 8 total DFS targets on this single root and they all work correctly.

I have used PSEXEC to open a remote command prompt as SYSTEM from a problematic computer to the share via DFS name and I get access denied.  This tells me that is my problem, but I don't know how to manipulate the permissions to be correct in this instance, nor do I understand why I would need to do that.  It has worked in the past with no problems.  There were no changes to the permissions (to my knowledge).

From the command prompt as SYSTEM, I can start an install of any of the software on the share using msiexec /i \\server\share\software\installer.msi - but not using the DFS path.

I don't think this is a permissions problem, rather a DFS problem.

Can anyone lend a hand here?  I would be most grateful.  Thank you!

Adam
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Author

Commented:
Another thing to note, the GPOs other settings are getting applied successfully.  This tells me that DFS to the sysvol and netlogon folder as local system are working correctly.
Neil RussellTechnical Development Lead

Commented:
Does the share AND NTFS permissions have "Domain Computers" set with at least Read Permissions?
Software installs from GPO with the computer account.
Mike ThomasConsultant
Top Expert 2010

Commented:
I have seen this recently when a namepsace had been created under the original namepsace (rather than folders) check that out.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
The permissions were not changed, but as a test I did add domain computers...still did not work.  I also added everyone group to both share and NTFS with no luck either.

@mojotech - can you elaborate on that further?  I don't understand what you're talking about.
Neil RussellTechnical Development Lead

Commented:
What is shown in the event log and have you got enhanced GPO debuging enabled on the workstation? What is recorded for that?
Mike ThomasConsultant
Top Expert 2010

Commented:
Check your name space in DFS management, under each name space you should see the folders right? well make sure they are not named like your name space. make sure the are just "foldername" not \\domain\etc\foldername like your name space is.

Make Sense? if not post a screen shot.
Technical Development Lead
Commented:
Also the permissions on the DFS link folder? Does that also grant read permission to the "Domain Computers" group?


"Remember that the are two objects, each with their own NTFS permissions.
First there is the folder within the DFSRoot that becomes the Link. These
permissions can be seen on the physical folder. Go to X:\DFSRoot and look at the
security settings on the folder.
Second are the NTFS Permissions on the target folder. These are the ones usually
exposed to the user but access via the DFS link also requires read permission on
the link folder itself.

Remember too that there may be more than one copy of the physical link if you
have more than one DFS root server. It is quite possible to get different
permissions on each copy which means that accessing the same folder via DFS can
sometimes experience one set of permission and sometimes a different set
depending upon which DFS Root server does the referral."

Quoted from  http://www.winvistatips.com/dfs-target-folder-permissions-t787822.html

Not 100% sure if that is correct of 2003, been a while :D

Author

Commented:
@Neilsr - that led me down the right path to resolve the issue.

Here is my explanation of the problem and resolution:
I added a new DFS root target from my windows 7 machine using the newest version of the tools.  This creates the share automatically for you and also sets the default NTFS permissions on the folder.  They were setup as this by default:
Share - Everyone - Read
NTFS - Administrators - Full, Creator Owner -  Special, System - Full, Users - Read.

I added Authenticated Users - Read and it worked.

Thank you all for the assistance.

Author

Commented:
This problem is popping back up for us intermittently.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial