ADSI Edit package location

[ZeroHour]

Hi

Just wondering if anyone had used ADSIedit to change the location of group policy deployed packages msi?

E.G. change a deployed package location from \\server1\software\blah.msi to \\server2\software\blah.msi

 

I know its probably not the best way but is there actually much risk of it borking anything? Its a simple edit.

We have the problem where the deployment server is being replaced and I dont want to have to redeploy. I just thought this could get around it as you are not re-adding packages to be deployed.

 

Thoughts?

[altecsole]

I've just done this using mtedit.exe - it's in the same folder as GPMC.

 

Basically:

 

1. Backup group policy

2. Open mtedit and load policy from backup location

3. Change destination to the new location; folder path only

4. Save migration table

5. Right click on original group policy and choose Import Settings; follow the prompts and point it at the migration table

 

Warning: Once you've done this any packages will be redeployed; there's no way to get around this.

[ZeroHour]

Hmm mtedit is slightly different then ADSI edit I think. Thats why I think it triggers redeployment for you. I hope that ADSI wouldnt but I will be trying it out at some point to confirm this.

I think that import settings part is what is forcing the redeployment at your end as it would be a logical thing to do. ADSI edit though edits raw AD.

[srochford]

I think you also need to edit the .aas file to make the change - it's possible that mtedit is also doing this. Clients will then "see" that the package has changed and redeploy.

 

I've never found a way to deal with this - it's why we now deploy everything from a DFS share. When you need a new server you add another replica, wait for it to fully replicate and then just remove the old server.

 

If you don't want to use DFS you could also use a DNS alias on the server - then when your server changes you just update DNS.

[ZeroHour]

Policies have a redeploy flag I thought that triggered redeployment, not clients checking for a changed path in a otherwise identical policy. ADSIedit just modifies the resulting aas because the aas is just the AD output I think.

[altecsole]

Hmm mtedit is slightly different then ADSI edit I think.

 

It is indeed. Sorry if I went off the point; I thought it might be useful to share the way I did it. Everything now moved to DFS and working nicely

[srochford]

Policies have a redeploy flag I thought that triggered redeployment, not clients checking for a changed path in a otherwise identical policy. ADSIedit just modifies the resulting aas because the aas is just the AD output I think.

 

That's right - what I should have added was that possibly the mtedit program triggers this process so that clients redeploy and they get updated to point to the new location.

 

Part of the reason for using MSIs is that they are "self healing" but this only works if they can find the original source. I suspect MS don't want you changing the source because then you break the healing bit. What I would have thought they could do, however, is add something which doesn't do a complete redeploy but just updates the data on the client machine to point to the new source.

[SYNACK]

When you change the deploy point and redeploy the application so long as you have not told it to remove the application immediately it just runs an update install over the top which is far quicker. Srochford is correct in saying that it breaks the self healing portion and can cause problems if the station attempts to pick up any extra components of the package at a later date.

 

The best way that I have found to do it is to remove the original install action from GP and tell it to leave the app on the machine, then redeploy the same application using a dfs share which can be have the actual source location altered when necessary. This redeploy method does trip up on Windows 2000 workstations though so if you have any of them these will need a full uninstall and reinstall of the application.