A good software deployment strategy is required when you are deploying an application from Microsoft Endpoint Configuration Manager. A robust deployment plan will help you in error free deployment , limit the damage in case of an issue and minimize the recovery efforts.
In this post, I will brief you about deployment approach which you should follow to plan your deployment. We will not dive into technical details such as creating a deployment in MECM.
The phased deployment approach is most commonly used deployment strategy used by most of MECM administrators. The deployment usually start with Test and Pre-pilot deployment and then move to Pilot deployment. The final phase is production deployment, which again split into multiple phase based on organization priority, deployment timeline, criticality, bandwidth, IT support personals availability etc.
You should carefully review deployment request submitted by requester. Please note that many requester come for deployment at last moment and they request deployment on large number of machine in very strict timeline. However going with the deployment in hurry do more harm than good.
The following points should be checked with requester before proceeding with deployment. This will help you in better deployment planning.
- Have they tested and certified the application?
- Application SME and their availability during deployment?
- Availability of vendor support agreement
- Inclusion of technology aware application user in pilot deployment to get the right feedback at right time
- Application criticality
- Whether its a new deployment or upgrade for existing users.
Test and Pre-pilot Deployment
This should be first step towards error free software deployment through MECM. Once you setup the Package or Application in MECM, you must test the deployment to ensure it’s successfully installed on targeted machines. You should also have a small scale deployment (Pre-pilot) to ensure application has correctly setup in MECM. The targeted users can be from your own deployment team or it may be other IT users who can quickly report if any issues encountered during deployment. Once you are satisfied with the result, you can move to next stage of deployment which is Pilot Deployment.
A pilot deployment prior to full production rollout is necessary. It’s almost impossible to simulate every aspect of your production environment in your test lab. A pilot deployment ensure extended testing of software in production like environment while limiting the scope to select group of users in your organizations.
Formation of pilot user group is one of the key part of pilot deployment. The MECM team usually maintain pilot user groups for organization wide deployments. However the requester should provide the list of pilot user for department specific application.
The question may arise that how many users you should have in pilot group? You may think about having 5% – 10% of your entire population. However the tricky part here is to have participation from all departments. Your pilot deployment participants should be representative sampling of the organization. They should also have knowledge of application or at least good understanding of computer so that they can easily communicate the problems to IT department. You have to ensure that pilot user’s list are up to date. Otherwise it can have adverse impact on deployment success rate. You should also have a strategy in place to maintain pilot user list up to date. We will talk about the same in future posts.
Communicating pilot user about the deployment is another key factor you should think about. The communication should have sufficient details for end user to share the deployment feedback with IT department. In many organization, Application owners own this piece and MECM administrator just focus on deployment. If the responsibility is not clearly defined in your organization then get this clarified from Application owners or deployment requestor to avoid any issues post deployment.
Once you reach end of the pilot deployment, please analyse the failure rate and failure cause carefully. If failure rates are higher then you should identify the root cause of the issue and work on remediation prior to moving ahead with production deployment. For the failures, don’t just look into percentage. The number also matter a lot. If you have 100 pilot user then 5% failure rate comes to 5 and may be acceptable. However, if you deploy the package on 10k machines then 5% failure can impact 500 users and it may lead to high number of incidents inflow to IT support.
You should begin with production deployment once fully comfortable with pilot deployment result. The production deployment should also divided into multiple phase with few days gaps in between for better control. The total number of phase again depends on different factors we discussed above. You can start with less number of client in initial phase and increase the count in later phase.
For example, you have 10k machines for deployment and want to schedule the deployment in five phases. You can plan something like below.
First Phase – 500
Second Phase – 1500
Third Phase – 2000
Fourth Phase – 3000
Fifth Phase – 3000
Phased Deployment – Collection membership planning
There are different way you can divide the users or machine in different phase. The static collection can help you in having exact number of client in a collection. You can also have dynamic collection based on different criteria. I am listing few options which you can use when creating collection for phased deployment.
Static Collection : You can simply divide total number of machines in desired batches and add them in collection. You can simply pick random machines or can use your own sorting method to divide them in multiple phase. A separate collection should be created for each phase.
Dynamic Collection : The dynamic collection can be based on different criteria and it can help you in targeting the deployment to different groups at a time.
For example, the collection membership can be based on below criteria’s.
- Machines member of specific AD group
- Machines in an AD Organizational Unit
- Machines where specific version of application is installed
- Machines with specific OS version
- Machines belongs to specific department
There can be N number of criteria’s. You should review the number of machines falling in each dynamic group and plan phased deployment collection accordingly.
- Configure Management Point for HTTPS | ConfigMgr | SCCM
- Configure Software Update Point for SSL | ConfigMgr | SCCM
- Deploy client authentication certificate for SCCM clients
- SCCM CMG Part 1 | Cloud Management Gateway (CMG) Setup Guide
- SCCM CMG Part 2 | Issue, Enroll & Export Server Authentication Certificate
- SCCM CMG Part 3 | Configure SCCM Site for SSL
- SCCM CMG Part 4 | Integrate Azure Active Directory with ConfigMgr
- SCCM CMG Part 5 | Setup Cloud Management Gateway
- SCCM CMG Part 6 | Validate CMG Health & Client Communication
- Location of smsts.log file during Operating System Deployment (OSD)
- Schedule SCCM Client Reboot through ConfigMgr
- Check Software Center Business Hours of Remote Computer
- SCCM Software deployment strategy
- How to deal with wrong deployment in ConfigMgr
- How to Initiate SCCM client agent actions using PowerShell
Subscribe to Techuisitive Newsletter
Be the first to know about our new blog posts. Get our newsletters directly in your inbox and stay up to date about Modern Desktop Management technologies & news.