[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Software installations deployment changing server

Posted on 2007-07-19
19
Medium Priority
?
1,294 Views
Last Modified: 2012-06-21
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.
0
Comment
Question by:enpq
  • 8
  • 6
  • 4
  • +1
19 Comments
 
LVL 8

Expert Comment

by:ajbritton
ID: 19526596
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
 
LVL 51

Accepted Solution

by:
Netman66 earned 1000 total points
ID: 19528084
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
 
LVL 8

Expert Comment

by:ajbritton
ID: 19529417
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
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 51

Expert Comment

by:Netman66
ID: 19530195
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
 
LVL 8

Expert Comment

by:ajbritton
ID: 19531138
@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
 
LVL 51

Expert Comment

by:Netman66
ID: 19531623
Yes, I sure can.  I'll post it from home this evening.

0
 

Author Comment

by:enpq
ID: 19534004
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
 
LVL 51

Expert Comment

by:Netman66
ID: 19536741
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
 
LVL 8

Expert Comment

by:ajbritton
ID: 19538006
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
 
LVL 51

Expert Comment

by:Netman66
ID: 19544303
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
 

Author Comment

by:enpq
ID: 19550843
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
 
LVL 8

Expert Comment

by:ajbritton
ID: 19550907
Can you confirm the actual share permissions and NTFS permissions?

0
 
LVL 51

Expert Comment

by:Netman66
ID: 19552646
Please tell me what ADSI object you are modifying.

It's critical that the values are perfect.

0
 
LVL 51

Expert Comment

by:Netman66
ID: 19552712
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
 

Author Comment

by:enpq
ID: 19555736
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
 
LVL 51

Expert Comment

by:Netman66
ID: 19561604
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
 
LVL 10

Expert Comment

by:blohrer
ID: 19577097
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
 

Author Comment

by:enpq
ID: 19577383
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
 
LVL 8

Expert Comment

by:ajbritton
ID: 19578042
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

Featured Post

Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
A hard and fast method for reducing Active Directory Administrators members.
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.

873 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question