Creating an effective deployment plan

As you move through these recipes, you're moving closer and closer to initiating an enterprise-wide SCEP deployment. Don't be scared, if you take the time to really think through the items in this recipe, you'll be setting yourself up for a pretty painless deployment.

Getting ready

To answer the following items, you will need to have a good understanding of your corporate network as a whole. If you were not a part of the initial SCCM 2012 design, you may need to reach out to your SCCM administrators to verify answers for some of the following items.

How to do it...

Working through the following items will walk you through the process of preparing your environment for SCEP:

  1. Has your SCCM 2012 been scaled out to support the number of SCEP clients you are intending to deploy?
  2. Have you implemented enough distribution points to supply SCEP definitions on a daily basis without affecting network performance?
  3. Have you disseminated enough information about the upcoming deployment to technical staff and end users?
  4. Have you fully tested your legacy AV removal procedure? If not absolutely 100 percent effective on all of your test clients, what is the expected percentage of failure?
  5. Have you created a procedure for dealing with failed SCEP installations?
  6. Have you created and tested SCEP policies for all the system types that your deployment targets?
  7. Is there an existing channel of communication for end users that experience performance issues after SCEP is deployed?
  8. Has there been a maintenance window created for deploying SCEP to Windows servers?
  9. Is your help desk ready to respond to an increased number of virus detections?
  10. Have you grouped your deployment targets into logical groups of systems that will allow for deploying in a phased manner?

How it works...

When considering the first item in this list, it's important to make sure that your SCCM 2012 environment is robust enough to support all of the SCEP clients you are intending to deploy. If your implementation of SCCM was in a pilot phase, make sure it's ready to support a production-wide deployment. Check to make sure there are enough primary sites and distribution points to cover your user base. Make sure good backup and disaster recovery procedures are in place.

The second item should have you thinking about placement of distribution points. A quick rule of thumb is that you don't want more than a handful of systems in a given site pulling updates over a WAN connection. If it's possible, plan to have a DP in each geographical site.

The importance of the third item, Have you disseminated enough information about the upcoming deployment to technical staff and end users?, should not be underestimated. With the proliferation of malware of the "fake" AV type, users have become increasingly savvy about what's in their system tray. It's a good idea to communicate with your end users about SCEP and what the icons should look like before initiating a deployment.

The fourth item, Have you fully tested your legacy AV removal procedure?, speaks to the reality of any production-wide deployment. No process is perfect, and when you're deploying something such as SCEP to every computer on your network, it's really a percentage game. It's better to be realistic about this and identify what you think the failure rate is going to be, and create a remediation plan to quickly deal with any clients that fail to install SCEP correctly. During your pilot phase, I would recommend deploying SCEP to a non-vital machine, without removing the legacy AV client. This will allow you to know what happens when both SCEP and the legacy AV are running on the same machine at the same time.

Because we're leveraging SCCM for deployment, the answer to the fifth item should be straightforward. Monitoring the success and failure of a SCEP advertisement is done within the SCCM console. If clients do fail to install SCEP, it's a good idea to have a manual SCEP installation procedure on hand.

The sixth item asks, Have you created and tested SCEP policies for all the system types that your deployment targets?. Remember that computers are grouped together logically by collection in SCEP. So if you've created, for example, an Exchange Server 2010 SCEP policy, you will need to have a collection of just Exchange 2010 Servers to which you apply this policy.

The seventh item asks if you've created a channel of communication between end users and the staff that are deploying SCEP. This is very important, as it will allow you to quickly address any performance issues by modifying SCEP policies as needed. That being said, try not to overreact to every user concern. The truth is, there are a lot of perception issues, where endpoint anti-virus is concerned. It's best to verify that an issue is really being caused by the SCEP client rather than create an abundance of unnecessary exclusions and exceptions.

The eighth item should get you thinking about your deployment plan for pushing SCEP to Windows servers. Usually, server operators will choose to manually install an AV client rather than automate the installation and run the risk of an unscheduled reboot. This is perfectly acceptable, however, just make sure that your operators fully understand the manual SCEP installation process and that your SCEP administrators follow up with confirming servers, which are showing up correctly in the SCEP dashboard. Manual installation procedures are covered later in this book.

The ninth item asks, Is your help desk ready to respond to an increased number of virus detections?. This should not be taken to mean that SCEP is going to cause your workstations to become infected. Quite the opposite, whenever an organization updates their AV to the new cutting-edge solution, it's normal to suddenly find infections that may have been going unnoticed. Just make sure your help desk staff is ready for this event, to avoid unnecessary panic.

The tenth item is meant to get you to think about how your computers are grouped together, either by geographical site or by their role. Stretching a deployment out over a period of time, maybe a couple of weeks, is always a better practice than trying to deploy to the entire organization overnight. This will ensure that the number of failed deployments is always small enough for your staff to respond in timely manner.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset