Group Policy Installation Files Not Found

[CAM]

Interesting bug I have encountered. I have been trying to get Group Policy to work and do an assigned installation to the computers that connect to the network domain. I've been stumped as it hasn't worked once and never done it before, though I followed instructions from Microsoft, guides here, everywhere, nothing works! I'm using MS Office 2007 and MS Works Compatibility Packs to test this out as we need them across the whole school anyway.

 

I brought up the Classlink 7 Default Domain Policy (since the Viglen interface won't let me edit GP Settings for computers as the page dies) using the Microsoft Management Console and put a new Software Installation in Computer Configuration -> Software Settings -> Software Installation. The files are held in \\servername\d$\blahblah\GPolicy and this is shared to allow Admins and Techs full control and Students and Teachers read access. The packages are accessed using \\servercluster\GPolicy and use Assigned to propagate the packages to computers.

 

Looking at Event Viewer on a laptop logged into a user account that I use for Library Supervision (giving me plenty of time to pore over these technical mess ups), it comes up with suppressed errors that are shown only in the Event Log.

 

Event Type: Error

Event Source: Application Management

Event Category: None

Event ID: 102

Date: 14/03/2008

Time: 09:25:32

User: NT AUTHORITY\SYSTEM

Computer: *****

Description:

The install of application Microsoft Works 6-9 Converter from policy ClassLink 7 Default Domain Policy failed. The error was : The installation source for this product is not available. Verify that the source exists and that you can access it.

 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 

Anyone have any idea whats up? I have given read access and you can see the folder with the installations when logged in but no luck. Doesn't even work on tech accounts that see everthing with full admin rights. It is recieving the Policy updates but isn't able to find the MSI files.

[m25man]

Im going to state the obvious,

 

if you have created a software installation policy that points to a valid share on the network containing the MSI you expect to install...

 

Have you included Domain Computers in the security tab?

 

Authenticated Users is the default setting when creating new policies but most software is installed on a per macine basis and therefore that group is not valid for software installations.

[powdarrmonkey]

Is the source on a share of a member server not a DC? We really, *really* struggled with this last summer when we built a new fileserver and moved all the software packages to it, ended up moving them back because no amount of cajoling, pleading and configuring would make it deploy from somewhere else.

 

So anything you come up with, grateful for some pointers.

Edited March 15, 2008 by powdarrmonkey
Tangled fingers.

[meastaugh1]

The files are held in \\servername\d$\blahblah\GPolicy and this is shared to allow Admins and Techs full control and Students and Teachers read access. The packages are accessed using \\servercluster\GPolicy and use Assigned to propagate the packages to computers.

...

Anyone have any idea whats up? I have given read access and you can see the folder with the installations when logged in but no luck. Doesn't even work on tech accounts that see everthing with full admin rights. It is recieving the Policy updates but isn't able to find the MSI files.

 

If you've assigned the packages to the computer, and only allowed teachers, student and techs read access to the package share, you will need to give the computer accounts access to the share. For example, create a group, add the computers accounts to it, then give the group read access to the share. (I'm referring to the share/NTFS permissions on the share where the MSI packages are located, not the GPO security permissions as this has been mentioned above).

Edited March 17, 2008 by meastaugh1
Clarity

[Lithium]

http://home.fnal.gov/~jklemenc/dl/AD-MSI-for-Dummies.doc

 

How I learnt

 

Authenticated Users includes Domain Computers - otherwise Computer GPO's wouldn't apply...? (And I read somewhere in TechNet Resources that it does)

[Michael]

@CAM - The one thing I notice is you're applying these policies to the Default Domain Policy which I wouldn't recommend.

 

I'm not familiar with Classlink 7, but how are your OUs organised? For example, I would recommend you have an OU called Curriculum, where all your student objects would be located, but also sub OUs called Lower School and Upper School etc... where you'd place your computer objects.

By applying policies under Computer Configuration on the Curriculum OU; this should be inherited by the sub OUs (unless you've blocked policy inheritance). This is where the GPMC can help a lot if required.

 

As for the directory where MSI files are located, as long as the permissions are correct and you're using a UNC path, it shouldn't make any difference (theoretically).

[CAM]

I have no idea how Viglen organises this stuff. Originally I tried using a policy on it's own but it didn't work so I assumed the one Viglen put in overrides it. So using the Policy window in Domain Properties, I edited the Policy called Classlink 7 Default Domain Policy to include software installs. There is nothing else there apart from one called Default Domain Policy (minus the classlink bit) and not touched that one.

 

On the Security Tab for the GPO, I have Domain Computers set to Read and on the share they are located, in the Security tab I added Domain Computers to allow Read and Execute, Read and List Contents.

 

I have just found another security tab though that I am going to try. On the sharing tab it says Permissions and that doesn't have Domain Computers...interesting. Will report back if that works. It's also a shared folder within a shared folder, would that have an impact?

 

@PowdarrMonkey: not sure what you mean by DC? It's located on a disk inside our main server, and the cluster consists of two servers, one of which takes over if the first fails.

[powdarrmonkey]

DC: domain controller. Our software store was traditionally on a controller, because we were short of machines, but when we moved it off to a member server everything stopped working.

[Michael]

So how are your users managed? It does sound like Active Directory is running, but you use something else to administer users? Sounds familiar to how RM and Ranger do things.

[CAM]

We use the Viglen Classlink Interface, though all the users are listed in AD anyway and can change passwords and lock them out from there (never had to try anything else though from AD).

 

I just tried that permissions tab and it didn't work.

 

I have this horrible feeling Viglen software is interfering but can't prove it or get support off them as they "don't cover that sort of stuff"

[Geoff]

Dump classlink, it's a pile of junk.

[Michael]

The Viglen interface/tool does sound like it's causing a problem. This is the main, fundamental problem with these third party solutions. Ironically RM, Ranger and Viglen (by the sounds of things) all run on top of Active Directory, so why not use that in the first place?

 

If Viglen cannot offer you any alternative, then some big decisions need to be made whether you genuinely need it at all.

[CAM]

I wish I could dump it, but higher ups want to keep it for now. Plus I'm still learning things I wish they taught on the degree I did! I do really really dislike not knowing whats going on in the network though but I guess I'll learn over time. Less then a years experience in a live environment

 

I just tried accessing the share as the NTAuthority\System user using the command line and it came up access denied. Definately can't find the share, but not sure why. Both Domain Computers and Authenticated Users are set to allow read access on the share. Using \\servername\drive$\share instead of \\servercluster\share also says access denied.

 

Does anyone have an example description of permissions I can see?

[Michael]

Have you applied permissions on both the Sharing and Security tabs?

[CAM]

I tried that earlier and it didn't work.

 

Not that it matters as I've been told stop playing with the server incase Viglen Picky Tech Support get in a huff if I crash it and have to call them and get charged. Boooo

 

I await the creation of a test rig network meanwhile:cool:

[SYNACK]

I think I know what your issue is. Your UNC path is using the \\server\drive$ share. This is an automated share that is only avalible to administrators and it isn't good practice to deploy from it.

 

You should create your own distribution share, I usually use dist$ with shareing permitions that allow everyone read and ntfs permitions that allow domain computers etc.

[CAM]

I just sneakily tried that and it worked! I can use an NTAuthority Comamnd Line to see the files, thanks! Though it won't work for the Office 2007 Compatability Pack though, because it has multiple files in it's folder? Works has just one MSI.

[m25man]

Well spotted Synack....

As usual back to the most basic of basics eh!

[SYNACK]

Though it won't work for the Office 2007 Compatability Pack though, because it has multiple files in it's folder? Works has just one MSI.

 

Not sure that I understand this one, once you have your \\server\dist$ setup you just add in the whole folders of the stuff that you want to install via AD. Ours has stuff like Office2k3 and Frontpage2k3 in it. They are all multiple file installs but you just need to point AD at the right MSI and it should go.

 

When you do an administrative install of something like office is will ask you where to put it, just need to specify a subfolder of your dist$ share and your sorted. Just make sure that all of the NTFS permitions are set to allow the appropriate groups ie Domain computers and all should be well.

 

If I remember correctly after extracting the compatibility pack you just put the folder in your dist$ share and set AD onto the MSI.

[SYNACK]

Well spotted Synack....

As usual back to the most basic of basics eh!

 

Yeap, its always the little things. The big things you are less sure about and so check more throughly. Its the little things that slide by and eat unsuspecting afternoons without warning, and of course dish out rather large helpings of irritation once they have been tracked down.

 

[CAM]

OK, each MSI installation has it's own folder in the share used for deploying these packages and NTAuthority can read the contents of the folders. The Works Pack appeared to deploy successfully last night and Event Viewer says success and the computer next to me now has Works 6-9 option in the Open File Box (hurrah!). But on the test machine I was using where a manual install of the Office 2007 Compatability Pack was deliberately kept off it, it has confimred NT Authority Access to the folder for the 2007 pack but Event Viewer was saying the Works one installed OK but the Installation Source still can't be found for the Office 2007 one.

 

Just to clarify folder contents;

 

O12Conv.msi

eula.txt

O12Conv.cab

readme.htm

Catalog\files12.cat

[SYNACK]

Perhaps the NTFS permissions did not apply to the individual files, only the top level folder. You can go to the properties of your shared dist$ folder and apply the settings to all sub folders and files, just set up the permissions that you want (domain computers etc.) for all of the sub folders and then use the advanced option under the security tab

 

Just check that the permissions are as they should be and check the "Replace permission entries on child objects" check box.

 

When you click ok it will make sure that all of the sub folders and files have the correct settings to be accessed (by the way I stuffed up the demo image above, it is supposed to be domain computers, oops ).

 

Hopefully this should solve the issues, if you have multiple domain controllers it may be an idea to add the 'everyone' group to read security as when a new computer is added to the domain it can take 10 - 15 minutes to show up in the domain computers group. This can prevent stations from getting the required software if they have just been added.

Edited March 19, 2008 by SYNACK

[CAM]

No luck. I may try putting it into it's own Software Installation GPO and see what that does.