Darren That was my understanding also, however it seemed like a good Idea to try this prior to Jamie's solution from yesterday. It certainly appears that the policy is running, and then failing to access the resources, this is what the installer log file says, so it seemed like a good first plan. However the syntax of the request seems to fail when I do it from the command line, I will now try Thorbjorn's syntax and see if that works or fails, I am expecting it to fail again. Then I would like to know what ACL's need to be in place on an application share folder where the source MSI exists for successful application deployment. Regards Craig From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia Sent: 15 February 2007 14:53 To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Installing Applications Fails[Scanned] Thorbjorn- I would think this would not work at all from the LocalSystem account because in order for it to access network resources, it would need to impersonate the machine account, which I didn't think was an automatic thing (i.e. during GP processing, there is an explicit call to ImpersonateUser). Darren From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Thorbjörn Sjövold Sent: Thursday, February 15, 2007 5:14 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Installing Applications Fails[Scanned] My suggestion was something like (If your AD domain DNS name is for example "parkstone.local") DIR \\parkstone.local\SYSYVOL\parkstone.local <file:///\\parkstone.local\SYSYVOL\parkstone.local> (from a client where you are experiencing the problem) Thorbjörn Sjövold Special Operations Software www.specopssoft.com <http://www.specopssoft.com/> thorbjorn.sjovold a t specopssoft.com Download our free tool for remote Gpupdate with graphical reporting, http://www.specopssoft.com/products/specopsgpupdate/ ________________________________ From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Judd Sent: den 15 februari 2007 13:49 To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Installing Applications Fails[Scanned] Thanks Thorbjörn I have again run an interactive session and tried what you said, but cannot seem to connect to the SYSVOL When I run NET VIEW from the domain controller in question I can see all the shares including NETLOGON AND SYSVOL but yet when I try to open them I receive the following error. "SYSTEM ERROR 123 The filename, Directory Name, or Volume label syntax is incorrect." When you suggested connecting to \\<domain.rootdomain\SYSVOL\<domain.rootdomain <file:///\\%3cdomain.rootdomain\SYSVOL\%3cdomain.rootdomain> what exact syntax should I use for this. Thanks Craig From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Thorbjörn Sjövold Sent: 15 February 2007 10:00 To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Installing Applications Fails[Scanned] You are running with the system credentials (system level) but you get prompted for credentials because the Redirector (Workstation service) figures out that to access the resources you request the current ones are inadequate. On the network the mighty Local System account is just another user, if you have security logging enabled on your share you would find the computer name with a $ sign , e.g. "mycomputer$" sign after it as it it is the computer SAM account name that is used when a computer is trying to access something. Your account obviously are still connected to the domain, since Group Policy is processing fine. In the System command prompt I assume you can read from SYSVOL. i.e. \\<domain.rootdomain\SYSVOL\<domain.rootdomain <file:///\\%3cdomain.rootdomain\SYSVOL\%3cdomain.rootdomain> ? Also do you have any problems accessing the shares as an ordinary user and not as the computer? HTH, Thorbjörn Sjövold Special Operations Software www.specopssoft.com <http://www.specopssoft.com/> thorbjorn.sjovold a t specopssoft.com Download our free tool for remote Gpupdate with graphical reporting, http://www.specopssoft.com/products/specopsgpupdate/ ________________________________ From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Judd Sent: den 15 februari 2007 10:21 To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Installing Applications Fails[Scanned] I did try this, it seems like an excellent way to determine access rights from the system level. I obviously have a problem because I am trying to connect to our shares Net view \\10.1.1.10\[sharename <file:///\\10.1.1.10\%5bsharename> ] and I get the error "System error 5 Access is denied" - this seems to be blanket across all shares, even if I have "everyone" read only and the "domain computers" read only on the shares and file level security. If I Net Use * \\10.1.1.10\[sharename <file:///\\10.1.1.10\%5bsharename> ] I get prompted for username and password. But I thought this was running at the system level? Any ideas? Regards Craig From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Thorbjörn Sjövold Sent: 14 February 2007 15:22 To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Installing Applications Fails[Scanned] If this is a computer based deployment, here is a neat little trick to check if this is permission problem: 1) Log on as an administrator on a computer where you have the problem. 2) Start a Command Prompt 3) Run the command "AT <A time close to now> /Interactive cmd.exe" 4) When the jobs runs a new command prompt will pop up where you are actually running with the security credentials as the System, i.e. the computer account. 5) Try to access the path where your files are located using for example DIR from the new command prompt. If you get an Access Denied here then you know it is a permission problem. Observe that this will not work in Vista due to all services and the system itself now have their Windows Stations in Session 0 and we mortals do not :) HTH, Thorbjörn Sjövold Special Operations Software www.specopssoft.com <http://www.specopssoft.com/> thorbjorn.sjovold a t specopssoft.com Download our free tool for remote Gpupdate with graphical reporting, http://www.specopssoft.com/products/specopsgpupdate/ ________________________________ From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia Sent: den 14 februari 2007 15:58 To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Installing Applications Fails Craig- This is a common problem I see and I'll be darned if I can find a common thread. But, some things to check. If you are deploying per-computer, try granting the Domain Computers group explicit read access to these shares and files. I know that it shouldn't matter if you already have the Everyone group but I have seen this help. 2nd thing-if the servers are 2003, SP1, there may be some SMB signing going on that the clients can't handle. Make sure that your security settings on the servers don't require SMB signing or that your clients are set to respond to it. Those are the two things that come to mind right away. Let us know if neither helps. Darren From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Judd Sent: Wednesday, February 14, 2007 12:45 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Installing Applications Fails Hi We have a medium sized Active Directory that has been in place for about 3 yrs, apart from the deployment of the Office Suite against the "domain policy" we have OU's that represent each group of machines and in turn we have associated applications for each department trying to install from these OU's. The office installation succeeds by the way. However it has come to light that these other apps fail to be deployed successfully, the LOG entry says that the "source installation file is not available". So we see that when we reboot a client workstation it says that it is installing the required application, it all appears to go through ok, the log in box finally appears, but yet the deployed application has not been installed. The source files are available at the share location, and all security and rights are available to everyone as read only. Any pointers as to why the apps are failing to deploy would be a huge help, thanks in advance. Craig Judd ICT Network Manager Parkstone Grammar School, Sopers Lane, Poole, Dorset. BH17 7EP 01202 605617 Parkstone Grammar School has taken every reasonable precaution to ensure that any attachment to this email has been swept for viruses. However, the school cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus check before opening any attachment. If you have any queries please contact ICT Support at Parkstone Grammar School.