2 replies to this topic

[mccracj]

I have a headquarters site (HQ) and 18 remote locations.  Currently when a new pc is ordered, we do the installs here and ship it to the user at the remote location (each location has a Win2k server on site).

We have deployed MSI/GPO packages at HQ - and it works wonderfully.  We can take a blank PC, drop an image on it, and push the MSI via computer GPO - and have a new PC up in ~15 minutes with usually everything they need.

For remote users, I have not found any 'best practice' type documentation or FAQ - so I'm asking for any help, documentation, or hints from others that have done this before.  More specifically:

1) How do people typically handle a remote install?  I want the pc setup, configured, and tested before being sent out, but I dont want to pull files from their local server.  I *think* I can use dfs, and if I make all my relative paths the same (ie: \\us\dfs\install\install.msi) - I can put the computer in their remote gpo, install it here where it points to the local dfs replica, and then ship it remote where it will pick up the remote replica.  Anyone ever tried this, or found another way to get around this hurdle?

2) What happens if I install an MSI here by double clicking it, then ship the file out to a remote location and have the exact same MSI pushed by GPO?

Thanks in advance.

Jason

[hambone]

when software is installed by gpo and also by allowing usiers to double-click on it the environments should be set up in a similiar way.  by default i believe that double-clicking a MSI simply invokes the file assoication info from the registry.  if you have customized the process, say allowing for the centralized creation of the MSI Logs, department applied customizations ( transforms ), or reduced/hull  ui requirements then these settings will have to be mimiced in the local file associations...  ( the topixs of blocking setting inheritance and setting up no overrides will be ignored for now )

regarding the issues relating to centralized and world-wide deployment it is usually required to setup a build strategy.  one such strategy might be to create a 'Base Build 1" consisting of only the OS and service packs.  this would then be 'hardened' to 'Base Build 2" by applying any c2 or organizationalt security requirements.  this secure build could then be tested and QA Released to the field as a secure-tested platform for use in the organization.

the final process would then involve creating a 'Base Build 3" system.  this system using the secure platform and adds the application layer to the mix.  the applications should be tested and approved for use on the secure platform as individual applications.  application inter-dependencies are then mapped and impact analysis is performed to identify product conflicts.

because the application layer is usually dynamic this process is efficient in the use of company resources and minimizes the requirements to provide full regtression testing when applications are added/deleted/modified from the supported applications list..l....

[mccracj]

I like the idea of the images (I was afraid that putting the MSI on here via an image and shipping it out wouldnt work), and that will probably work for me.  I'll have to do a bit more testing, but thanks for the replies.

Jason