Software installations deployment changing server

Hi,

We are currently in the process of changing the location of some administrative installation from one server to another (for exemple Microsoft Office). These software installtion are being installed through group policies and all working fine. Now, the installation files have all been copied to our new server and the shares and files permission are all good. So, from there I used the "migration table editor" (mtedit.exe) that comes with gpmc. I did a backup of my policy from the gpmc console and then launch the mtedit.exe tool. I then made the change for the new unc path, pointing to my new share on my new server. I then did an import settings on my policy from the gpmc console and used my new migration table, everything went fine.

Now for the real question. When I did a gpupdate /force on my test pc, the software that was previously installed from the old share on the old server, got uninstalled then reinstalled completely. Why is that ?

Since my 2 servers are on the same domain, and that the gpo didnt change (only the software's unc did changed), then why did it got uninstalled and reinstalled ? Also note that the option "Uninstall this application when it falls out of the scope of management" has been checked from the very beginning in the gpo.

If that is way for it to works, then is there a way to change software distribution from one server to another without having my software uninstalled / reinstalled ?

All change made in the gpo were made through Windows server 2003 enterprise sp2. First server is running Windows adv. server 2000 sp4 and the new one is the Windows 2003 enterprise sp2.

Hope I described my problem well enough for you to help me. If not, then I'll send more info.
enpqAsked:
Who is Participating?
 
Netman66Commented:
You could have used ADSIedit to change the target UNC path for your source files in those GPOs rather than update the tables.

Updating the tables, effectively caused this anomaly - which would be the normal thing to occur.

No need to worry - it's a bit of a PITA, but it's self-correcting (as you're seeing now).

0
 
ajbrittonCommented:
The reinstallation is normal behaviour unfortunately. The only way around this is to use DFS to create share paths which are non-server specific. This effectively decouples the share path from the serve name. If you deploy software from a DFS based share path, the share can be moved to any server without needing to reestablish the software assignments.

If you had configured every application such that the 'uninstall this application when it falls out of scope...' to be cleared, then the software will no uninstall, but the reinstall will still take place. This would save some time though.

0
 
ajbrittonCommented:
I don't think using ADSIedit would help. Machines that have already been deployed would still look for the original path. Also, the settings are stored in an .AAS script which is somewhere under the SYSVOL folder.
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
Netman66Commented:
I've done this a number of times and the workstation uses the policy to determine the source.  Once corrected, the stations don't complain or try to reapply the policy.
0
 
ajbrittonCommented:
@Netman66: Thats very interesting to know. Can you point me to a resource which shows the paths in ADSIedit. Maybe a script could be constructed to do some kind of global replacements.
0
 
Netman66Commented:
Yes, I sure can.  I'll post it from home this evening.

0
 
enpqAuthor Commented:
Hello again,

I've been toying all day with adsiedit, changing software installation from one server to another and I've hit a glitch.

Everything seems to work fine; I did move my software from 1 server to another, change the unc in the adsiedit for my software package and did a gpupdate /force on my workstation and everything was still ok (no uninstallation or change). I then went to gpmc, got to my policy and I removed my workstation from the security filtering in the scope tab. I then redid a gpupdate /force on my workstation, it rebooted and the software did uninstalled. So I tought everything was perfect. Then, just to go a little further, I did put back that same workstation back in the security filtering so the software would install back, did a gpupdate /force on that same workstation, it rebooted and nothing happened... it didn't reinstall the software. I went to see in the event viewer and found those entry:

Source: Application Management
ID: 102
The install of application "{Package Name}" from policy "{Policy Name}" failed. The error was The installation source for this product is not available. Verify that the source exists and that you can access it.

Source: Application Management
ID: 303
The removal of the assignment of application application_name from policy GPO_name succeeded.

Source: Application Management
ID: 108
Failed to apply changes to software installation settings. Software changes could not be applied. A previous log entry with details should exist. The error was The installation source for this product is not available. Verify that the source exists and that you can access it.

Source: Userenv
ID: 1085
The Group Policy client-side software installation failed to execute. Please look for any errors reported earlier by that extension.

Hope you can help.


0
 
Netman66Commented:
Are the share and NTFS permissions correct for the source files?

Share - Authenticated Users - Full Control
NTFS - Authenticated Users - Read and Execute
          SYSTEM and Administrators - Full Control.

Pass inheritance down (rewrite permissions on all child objects).
0
 
ajbrittonCommented:
You could also try deploying to a test workstation which has not previously had the application installed. If this works, then the GPO and OU are probably OK and the problem lies on the other workstation which has had the software previously.

I did a bit of digging on this and although I found a couple of threads where people claimed to have found the answer to this problem, I have a nagging suspicion that it may not be quite as simple as we all hope. There may be registry entries left behind on the PC which originally installed the software from the old server. If that is the case, they may be confusing things.

It ought to be possible to write a script to 'clean up' these registry entries following an un-install, but it may not be a 'trivial' task.

Here's hoping it's a permission issue. I really want Netman66 to be right on this one as I am likely to face the same problem myself on a lot of sites in the not to distant future.
0
 
Netman66Commented:
Strictly speaking, the GPO UNC path is changeable within AD using ADSIEdit.  Yes, Windows Installer will remember the old path (from the Installer registry key), but if the software is governed by policy then the policy overrides the installer when it comes to management.

Most of the time, the msi gets cached locally in Windows\Installer so it can repair minor things without using the source.

By the look of that error it appears to be permissions or replication has not yet cleaned up all the GPOs across the replicas.
0
 
enpqAuthor Commented:
Just to keep you informed,

I did a check on my permissions and share and everything is ok. I did a gpupdate /force on my workstation just to verify the acls, rebooted and got the same events logged in my event viewer. So the problem is not on the acl level.

I also tried an installation on a newly formated workstation, then put it in my software scope in my gpo, then did a gpupdate /force, it rebooted and got the same problem on this one too (same 3 events in the event log). I also tried to install the software directly from the share and everything installed fine.

So now I'm thinking the problem must be on the server side, but where ?
0
 
ajbrittonCommented:
Can you confirm the actual share permissions and NTFS permissions?

0
 
Netman66Commented:
Please tell me what ADSI object you are modifying.

It's critical that the values are perfect.

0
 
Netman66Commented:
You should be modifying the following:

Domain>
    DC=domain,DC=com
        CN=System
            CN=Policies
                CN={GUID of policy involved}
                    CN=Machine
                        CN=Class Store
                            CN=Packages

Modify the following attributes:

msiFileList = drive path to msi ***NOTE the leading number - this is important.
msiScriptPath = UNC path to share and msi.

The other issue of .AAS policy files might not impact you as once the policy changes it *should* regenerate the file.  I have to test a bit here, but in the past just those two elements were generally successful.

You could delete the AAS file in that policy and redeploy the application which would trigger a repair, but not a complete reinstall.  

You may also want to toy with this idea as well:  http://www.gpanswers.com/community/viewtopic.php?t=1118

0
 
enpqAuthor Commented:
Yes, I confirm that my NTFS share and permissions are good, Everyone - full control on the share and everyone in read / execute, list folder and read on security. System is inherited and as access in full control. I also did a propagated on all files and sub folder. I'm very positive that everything is ok.

As for the element being modified in adsiedit.msc, yes I was just where you point out Netman66. I did modified the msiFileList; my msi file is 0:\\servername\unc path\filename.msi and 1:\\servername\unc path\filename.mst (both file are in the same folder).

As for the msiScriptPath, do I have to modify this ??? It's currently pointing to my .aas file (\\domainame\SysVol\ENPQ\Policies\{C3F4414D-8CE4-41FE-8D1A-7992E1DA99E7}\Machine\Applications\{3553D9B8-E5A9-47FD-B010-0A0AE523AEF0}.aas


BTW, I trully appreciate the help so far.
0
 
Netman66Commented:
You're right, I opened up the attribute completely to see the full path and it's pointing at the aas.

Did you try using the Migration Table Editor?  It would be interesting to see the difference if you moved a different package with that tool and compared them.

It may, in fact rebuild the aas file which is likely what is causing your problem.

0
 
blohrerCommented:
Hi all,

I am looking to do this myself, and in this thread a lot was thrown around.  

Enpq: did the "used ADSIedit to change the target UNC path " work without any other changes?

Bill
0
 
enpqAuthor Commented:
Didn't had a chance to do more test, I have like 10 things to do right now, but I plan to do some more testing with a "snapshot" software; take a snashot of my server, do some changes with the migration table editor and then do an after snapshot to see what changed. I'll keep you posted as soon as I do my testing.
0
 
ajbrittonCommented:
This article may shed some light on the process if not directly solving the problem...

http://diaryproducts.net/about/operating_systems/windows/move_software_package_to_another_gpo
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.