Don't conduct a manual install when your SCCM deployment fails - Stick to the SLA

Introduction

In today's article, we're bringing a specific scenario into discussion and proposing the right solution to manage similar situations.

It will be focused on conducting a manual installation of an app if your SCCM deployment fails. This also applies to any Configuration Manager tools such as Ivanti Landesk, Emporium Matrix42, etc.

We've talked about manual installations previously when we explained the reasons why your manually installed applications count should be zero. In that same article, we mentioned why you should package and integrate an app using configuration management tools regardless of the number of users it will have.

We suppose that in an enterprise environment, non-IT users will not have admin privileges and will not be able to install software by themselves. All installations/deployments are done by the IT department.

Deployment Scenario

First, let's assume your application is already packaged and integrated into the SCCM environment. Meaning that the package already went through the entire process, including testing, and it is now ready for deployment.

Once we've reached this point, there are 2 deployment scenarios: Mass Rollout and Targeted deployment.

• Mass Rollout: When you have an application package and you deploy it on the entire infrastructure
• Targeted deployment: When you have one or more specific computers on which the software must be installed.

These days, mass rollout deployments are handled by IT Administrators because they require more responsibility and a higher security role access in SCCM. It is considered a major task and the entire infrastructure is in your hands.

The usual success rate agreed on the SLA (Service Level Agreement) is around 90%, so you don’t need to worry about those machines where the deployment failed, if the process meets this requirement.

What about targeted deployments?

In an enterprise environment, there are a lot of situations when users request the installation of specific applications on their machines.

Usually, these requests are handled by the IT-support or service desk department using third-party or in-house-developed web-based applications that are directly linked to the SCCM.

Generally, service desk or support agents have limited access to these types of applications to avoid them from accessing the main settings and potentially breaking or damaging the entire infrastructure.

The manual install temptation

Service desk and support agents operate on ticket requests and directly interact with the users, therefore a different SLA applies to them.

Imagine this scenario: A regular day working as a support agent, you receive an urgent request from a user requiring a specific software to be deployed on his computer as soon as possible. You start the deployment and it fails. The SLA clock is ticking and the user puts pressure on you, demanding this software to be installed on his machine immediately.

Being under pressure could lead to rash decisions and possible mistakes especially when it comes to the least experienced staff. You may think that connecting remotely to the user’s machine and manually installing the software will solve the issue and close the ticket request fast and easy.

Technically, you're meeting the requirements set in the SLA. But, is this the right decision?

What to do?

In most IT guidelines, there's a process in place that states what to do in case you receive errors during an operation that is above your area of expertise. What should be the right step to take? You should pass the ticket to the correct group to investigate why the deployment failed. Period.

Don’t let the user manipulate you. Follow the rules “by the book” and review the guidelines to make sure you know what you can and can't do.

After you transfer the ticket or request to the next group, it is not your responsibility anymore. Make sure you explain this to the user and most importantly, document your ticket.

Why?

Now that you know what to do, or in this case … what not to do, let's go through the reasons why you should not manually install an application software if your deployment fails.

Hidden and more serious problems. A failed deployment does not always mean there's a problem with the application. As a matter of fact, there may be some more serious issues with the computer and any other future deployments may not work. In this situation, the machine will probably not be patched in the future and will have security vulnerabilities.

Application reporting. In a mass rollout, since the application is installed manually, the SCCM reporting will still see it as a failed deployment and you will have a misleading report in the end. To solve this issue you will have to tweak your detection methods.

Application misconfiguration. Usually, there are company-specific configurations that are included within the application package. By manually installing an application, there is a big chance for these settings to get ignored causing the software not to work properly - leading to more issues and tickets.

Application update issues. There are situations where the manually installed application will not update in future deployments. This will take extra effort, as someone will have to create a different detection method to include the manually installed software and additional install scripts.