xPDT – Profiles

In “xPDT – the next generation of deployment automation”, I outlined the requirements and challenges of automating distributed deployment. This post will examine the challenges associated with profiles.

Some setups assume that the credentials under which they are running have a user profile present.  Sometimes this is because the setup copies files to the user profile and then installs from that location – for example, System Center Operations Manager does this.  Other time, secrets from the user profile are used to protect service accounts during installation – for example, SQL Server does this.  The approaches I described in my previous post don’t guarantee the presence of a user profile – if the credential being user has previously logged on to the system, there will be a user profile but otherwise there will not.

To solve these scenarios, I use two additional approaches in xPDT resources.  For SQL Server standalone instances, since it does not require access to remote machines during installation, I install as system – the system profile provides everything needed.  System Center Operations Manager does need access to remote machines during setup, so can’t use system – so I fall back to the approach that was used in the original PDT, which is to run the installation using the task scheduler.  When using task scheduler, the default user profile is used, which has the appropriate folders to cache the installation files.  The start process functions in xPDT.ps1 take a switch –AsTask that instructs it to use a scheduled task with a credential instead of PInvoke.

So, now we have all the approaches we need to install all components.  In my next post, I will discuss dependencies during deployment – both on the same machine, and across machines.