Group Policy software installation fails - windows installer error %1612


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!

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ahahumAuthor 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 LeadCommented:
Does the share AND NTFS permissions have "Domain Computers" set with at least Read Permissions?
Software installs from GPO with the computer account.
Mike ThomasConsultantCommented:
I have seen this recently when a namepsace had been created under the original namepsace (rather than folders) check that out.
Maximize Customer Retention with Superior Service

The IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more to help build customer satisfaction and retention.

ahahumAuthor 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 LeadCommented:
What is shown in the event log and have you got enhanced GPO debuging enabled on the workstation? What is recorded for that?
Mike ThomasConsultantCommented:
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.
Neil RussellTechnical Development LeadCommented:
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

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ahahumAuthor 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.
ahahumAuthor Commented:
This problem is popping back up for us intermittently.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.