Some time back I put a Windows 10 build together for a large company using the Ivanti landesk deployment product. It was an interesting project in itself and I was grateful to have been given the opportunity to learn about a new systems management product. My specialty has always been Microsoft Endpoint Configuration Manager, and before that it was called SCCM, and before that it was called SMS - and to learn about a new product is always very interesting.
One of the features I liked about Ivanti was the ability to nest task sequences so that a task sequence for a set of applications could be called from with a base task sequence. Thankfully Microsoft implemented nested Task Sequences also in build 1710.
In Microsoft Endpoint Configuration Manager (Build 2002 and above) Microsoft has also implemented the ProvisionTS switch as an option for the ccmsetup.exe Configuration Manager Client installation file. When the CM client is installed, the Task Sequence of the deployment ID given to this switch is initiated as soon as the client has successfully registered to its Configuration Manager site.
There are a number of clear advantages to this feature as it stands, and a number of possibilities to build on the feature.
1) Tune up Task Sequence - If SCCM is being implemented first time in an organisation or in a department, client push discovery alongside and client push installation, along with ProvisionIT allows a true up. All machines to run the task sequence and all machines to be brought up to a company standard. And in quick time as well.
2) Client Reinstall - Uninstall clients and de-register from SCCM. Install once more and the tune up task sequence applies a company standard of applications and configurations.
3) Delegation of responsibility - quite often a company will want to delegate part, but not all of the build to an external IT management company. Nested and independent task sequences are a convenient way of achieving this: and it is clear which entity is responsible for a build failure after investigating which of the task sequences did fail.
4) Those applications whose completion time is not really a completion time. We have all seen this one where the application feeds back an install complete status and the build then moves on to the next step in the task sequence. But then we find the application is still doing something, and that something interferes with the build and causes a failure. Putting this application in a separate task sequence to be called by ProvisionTS is a convenient way of working around this sort of application snag.
5) A baremetal build can compartmentalized so that there is a core build - critical to getting a user up and running; and a less critical subsection of the business build. For instance a core build might included Windows 10, all security updates, Office Pro Plus and the required dot net frameworks - this in itself will allow the user to start working on documents, create and receive emails, access company portals and submit reports. In addition a role specific task sequence of less critical applications can be deployed using the ProvisionTS switch or the nested task sequence: for instance, a technical engineer might have the Visio application as well as Microsoft's systernals tools deployed via the less critical task sequence run through the ProvisionTS variable. Thus:
6) Build reduction time. In an existing scenario the base build is applied, and then the machine is left on the bench waiting for all the required applications, deployed via AD integrated collections and deployments, to install. This can take hours or days depending on polling schedules. If the collections are hardware inventory based then the total build time can even take weeks: again depending on the hardware interval time set in SCCM (default is seven days). It needs to be tested but an option here would be to use a Status Filter Rule force a client reinstall after a base is installed.
7) Zero Touch Upgrades are facilitated. In most cases today, if we are able to apply an OSD build to a device at the user's desk - we still require an engineer to plug a machine into the network, PXE network boot the device, and select the task sequence. We cannot expect a user to perform this operation. However we supply the user with a machine which has a superseded, but approved, corporate build already installed on the hard disk: the user is instructed to switch on the device and the upgrade Task Sequence commences as soon as the device's SCCM client registers with the SCCM site. The Task Sequence that is commenced is termed a refresh task sequence; in this scenario however it is a refresh but without user data migration - thus in terms of definition there is little change from a bare metal build.
8) The ProvisionTS variable provides a way of achieving, for the on-premise arsenal of deployment tools, what Autopilot achieves as an in cloud deployment tool. In essence an active build need not be modified as often as it currently is - but all the configurations and applications are overlay-ed using a task sequence deployed to the All Provisioning Devices collection. This can be achieved using the offline join domain process.
9) We shouldn't forget that the SCCM client installation is a standard installation and can be deployed via Intune with whatever Task Sequence is desired, thus this feature through Intune can enhance existing builds and also autopilot builds in an on premise scenario.
Using ProvisionTS
In this example I have a simple Application based Task Sequence that installs Notepad ++ and copies the famous cmtrace.exe log file viewer to the windows directory
We will test the following.
1) Create a deployment for our application task sequence to the new Provisioning Device(Provisioning Device) collection.
2) Install the SCCM client using following command line: ccmsetup.exe /SMSMP=SERVER2 SMSMP=SERVER2 PROVISIONTS=<deployment ID of the application task sequence>
3) Verify that the application task sequence is run after the client is registered in SCCM.
Creating the TS deployment
1) Open the CM console and navigate to Software Library\Operating Systems\Task Sequences. Right click on the custom application task sequence and select Deploy. The Specify general information for this deployment window appears. In the collection section click on browse and select the All Provisioning Devices collection. Click on Ok and then Next
One of the features I liked about Ivanti was the ability to nest task sequences so that a task sequence for a set of applications could be called from with a base task sequence. Thankfully Microsoft implemented nested Task Sequences also in build 1710.
In Microsoft Endpoint Configuration Manager (Build 2002 and above) Microsoft has also implemented the ProvisionTS switch as an option for the ccmsetup.exe Configuration Manager Client installation file. When the CM client is installed, the Task Sequence of the deployment ID given to this switch is initiated as soon as the client has successfully registered to its Configuration Manager site.
There are a number of clear advantages to this feature as it stands, and a number of possibilities to build on the feature.
1) Tune up Task Sequence - If SCCM is being implemented first time in an organisation or in a department, client push discovery alongside and client push installation, along with ProvisionIT allows a true up. All machines to run the task sequence and all machines to be brought up to a company standard. And in quick time as well.
2) Client Reinstall - Uninstall clients and de-register from SCCM. Install once more and the tune up task sequence applies a company standard of applications and configurations.
3) Delegation of responsibility - quite often a company will want to delegate part, but not all of the build to an external IT management company. Nested and independent task sequences are a convenient way of achieving this: and it is clear which entity is responsible for a build failure after investigating which of the task sequences did fail.
4) Those applications whose completion time is not really a completion time. We have all seen this one where the application feeds back an install complete status and the build then moves on to the next step in the task sequence. But then we find the application is still doing something, and that something interferes with the build and causes a failure. Putting this application in a separate task sequence to be called by ProvisionTS is a convenient way of working around this sort of application snag.
5) A baremetal build can compartmentalized so that there is a core build - critical to getting a user up and running; and a less critical subsection of the business build. For instance a core build might included Windows 10, all security updates, Office Pro Plus and the required dot net frameworks - this in itself will allow the user to start working on documents, create and receive emails, access company portals and submit reports. In addition a role specific task sequence of less critical applications can be deployed using the ProvisionTS switch or the nested task sequence: for instance, a technical engineer might have the Visio application as well as Microsoft's systernals tools deployed via the less critical task sequence run through the ProvisionTS variable. Thus:
- Risk reduction requirements are implemented.
- Change control is expedited with less risk.
- Testing times are reduced because the core of the testing is done on the application task sequence.
6) Build reduction time. In an existing scenario the base build is applied, and then the machine is left on the bench waiting for all the required applications, deployed via AD integrated collections and deployments, to install. This can take hours or days depending on polling schedules. If the collections are hardware inventory based then the total build time can even take weeks: again depending on the hardware interval time set in SCCM (default is seven days). It needs to be tested but an option here would be to use a Status Filter Rule force a client reinstall after a base is installed.
7) Zero Touch Upgrades are facilitated. In most cases today, if we are able to apply an OSD build to a device at the user's desk - we still require an engineer to plug a machine into the network, PXE network boot the device, and select the task sequence. We cannot expect a user to perform this operation. However we supply the user with a machine which has a superseded, but approved, corporate build already installed on the hard disk: the user is instructed to switch on the device and the upgrade Task Sequence commences as soon as the device's SCCM client registers with the SCCM site. The Task Sequence that is commenced is termed a refresh task sequence; in this scenario however it is a refresh but without user data migration - thus in terms of definition there is little change from a bare metal build.
8) The ProvisionTS variable provides a way of achieving, for the on-premise arsenal of deployment tools, what Autopilot achieves as an in cloud deployment tool. In essence an active build need not be modified as often as it currently is - but all the configurations and applications are overlay-ed using a task sequence deployed to the All Provisioning Devices collection. This can be achieved using the offline join domain process.
9) We shouldn't forget that the SCCM client installation is a standard installation and can be deployed via Intune with whatever Task Sequence is desired, thus this feature through Intune can enhance existing builds and also autopilot builds in an on premise scenario.
Using ProvisionTS
In this example I have a simple Application based Task Sequence that installs Notepad ++ and copies the famous cmtrace.exe log file viewer to the windows directory
We will test the following.
1) Create a deployment for our application task sequence to the new Provisioning Device(Provisioning Device) collection.
2) Install the SCCM client using following command line: ccmsetup.exe /SMSMP=SERVER2 SMSMP=SERVER2 PROVISIONTS=<deployment ID of the application task sequence>
3) Verify that the application task sequence is run after the client is registered in SCCM.
Note: If your task sequence is failing at the software distribution steps you may need to configure a Run Command Line step to enable software distribution. Execute the following code:
WMIC /namespace:\\root\ccm\policy\machine\requestedconfig path ccm_SoftwareDistributionClientConfig CREATE ComponentName="Enable SWDist", Enabled="true", LockSettings="TRUE", PolicySource="local", PolicyVersion="1.0", SiteSettingsKey="1" /NOINTERACTIVE
Creating the TS deployment
1) Open the CM console and navigate to Software Library\Operating Systems\Task Sequences. Right click on the custom application task sequence and select Deploy. The Specify general information for this deployment window appears. In the collection section click on browse and select the All Provisioning Devices collection. Click on Ok and then Next
2) On the Specify setting to control how this software is deployed ensure that Required is selected under Purpose and click on Next.
3) On the Scheduling windows click on the New button and in the Assignment Schedule window click on Assign immediately after this event: and select As soon as possible.
4) Click on OK and then Next. Accept the defaults for the User Experience windows and click on Next. Accept the defaults for the Alerts windows and click on Next. Accept or modify the Distribution Points window as required and click on Next. Review the Summary and click on Next. The Deployment is created. Click on Close.
5) In the lower section of the right pane your Task sequence ensure that Deployments tab is selected and that the the Deployment ID column is listed. If it is not then right click on the ribbon and select Deployment ID.
6) Make a note of the Deployment ID. This is required for the next set of instructions. In this case it is S0120003.
Deploy the Client using ProvisionTS
Copy the ccmsetup.exe file to the c:\windows directory of your test client. Open a command prompt and run the following command ccmsetup.exe /MP:<name of CM management point server> SMSMP=<name of CM management point server> PROVISIONTST=<Deployment ID of the task sequence deployed to the Provisioning Devices collection. In this example my command line is:
ccmsetup.exe /MP:SERVER2 SMSMP=SERVER2 PROVISIONTS=S0120007
The progression of the installation can be monitored in the c:\windows\ccmsetup\logs\ccmsetup.log file.
The installation completes
The task sequences fires up and completes.
Using ProvisionTS in an Operating System Deployment Task Sequence
In this test case scenario I run a standard Zero Touch MDT task sequence to install Windows 10 Enterprise build 2004. I configure the ProvisionTS variable in the Setup Windows and ConfigMgr task sequence step. I have created a new deployment and so the deployment id is different from above. In addition I have no other switches to feed into the step as can be seen.
ProvisionTS=S0120009
I tested the OSD MDT build on a Hyper-V guest machine and it successfully completed at July 4 at 10:54:09.
Observing the status messages and without touching the newly built virtual, it was observed that the additional task sequence specified in the ProvisionTS switch started installing at 10:56:24. So that is just a little over two minutes wait time and from my point of view, that is a good result indeed.
Twenty seconds later Notepad ++ 7.8.7 has installed.
Twenty seven seconds later the supplementary task sequence has completed.
No comments:
Post a Comment