Group Policy software installation fails - windows installer error %1612
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\in
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
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\in
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
Does the share AND NTFS permissions have "Domain Computers" set with at least Read Permissions?
Software installs from GPO with the computer account.
Software installs from GPO with the computer account.
I have seen this recently when a namepsace had been created under the original namepsace (rather than folders) check that out.
ASKER
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.
@mojotech - can you elaborate on that further? I don't understand what you're talking about.
What is shown in the event log and have you got enhanced GPO debuging enabled on the workstation? What is recorded for that?
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.
Make Sense? if not post a screen shot.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@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.
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.
ASKER
This problem is popping back up for us intermittently.
ASKER