A:
Changing the path is not easy and might not be worth it for you! Ordinarily, when you publish or assign an application using Group Policy Object (GPO)-based software installation, you cannot go back from the GPO editor tool and change the path you assigned to the .msi file that installs the application. Your only choice is to delete and re-add the deployed application. However, you can directly edit the Group Policy Container (GPC) object within Active Directory (AD), then follow a series of steps to change the path to the file.Although this mechanism is not supported by Microsoft, it does work and is useful to know if you need to change a fair number of applications and don’t want to have to delete them and start over. However, you will have to use the redeploy feature within software installation, which
To use this trick, you need to have installed the Windows 2000 (Win2K) Support Tools, which contains the ADSI Edit Microsoft Management Console (MMC) snap-in tool. Let’s walk through this technique with an example. Figure 7.6 shows that I’ve created a GPO that deploys the
Win2K Administration Tools as a published application.
Figure 7.6: Viewing an application deployed via GPO.
When I published this application, I entered the path for the .msi file package that installs it. That path was a share on my server: \\yquem\packages\adminpak.msi. After the application is
published (or assigned), the path to the package is not exposed anywhere. However, using ADSI Edit, I can directly edit the AD attribute that controls where that package is found. Here are the steps to follow to edit this application’s path:
1. From the Group Policy editor tool, right-click the name of the GPO, and select Properties
to view the GPO’s globally unique ID (GUID). Make a note of the GUID.
2. Start the ADSI Edit MMC tool (adsiedit.msc) and, if you aren’t already, connect to the domain naming context for your domain.
3. Under the domain naming context, drill down into the CN=system, CN=policies folder and locate the folder that corresponds to the GUID of your GPO, as Figure 7.7 shows.
Figure 7.7: Viewing the GUID folder of a corresponding GPO in ADSI Edit.
4. After you’ve located the GUID, you will see a machine and user subfolder. In our case, because we are editing user-based software installation, I will expand the user folder to reveal a CN=Class Store subfolder.
If you expand the Class Store subfolder, you will expose a CN=Packages folder that contains one or more GUID-named objects of class packageRegistration (see Figure 7.8). Each packageRegistration object corresponds to a deployed application within the GPO.
5. Double-click the desired packageRegistration object. (If there is more than one, you will need to determine which one is the application you need to modify. To do so, double- click the object, and, from the drop-down list of properties for the object, choose displayName to see which application you’re editing).
6. After you’ve located the correct application, choose the msiFileList property to see the
list of current file paths for your application. You will notice that this list can have multiple values. The reason is that if the original path was a distributed file system (Dfs) share, the GPO will cache all the available replicas under the share where the package can be found.
7. To edit a path value, select the value to edit, and click Remove to move the path into the edit attribute dialog box (see Figure 7.9).
Figure 7.9: Editing the path to an .msi file in the deployed application.
8. You can now edit the path, being careful to leave the numeric reference (in Figure 7.9, the reference is 0:) in place. After you’ve edited the reference to point to a new path, click Add to commit it to the property.
9. The next step is to temporarily relocate the Application Advertisement Script (.aas file) that was created when you first deployed the application. This .aas file contains hard- coded references to the old .msi file path. For my example, the .aas file is located in
Figure 7.10: Viewing the .aas file that is created when a GPO-based application is deployed.
10. Next, go back to your deployed application within the GPO editor tool. Right-click the application name, choose Tasks from the context menu, then choose Re-deploy
Application. You will receive a failure message—acknowledge it.
11. If you go back to the SYSVOL folder from Step 10, you’ll see a new .aas file, called temp.aas, has been created. Delete this file, and move the old .aas file back into this folder.
12. Again, return to the GPO editor tool and redeploy the application one more time. You should not receive any errors, and the application will now be installed from the new location!
You may very well be thinking that this process is too much work to go through just to change an application’s deployment path. That may be true, but there may be reasons why you can’t simply delete and re-add an application. In that case, this technique works.