In my previous article I explained how to deploy an MSI package with System Center Configuration Manager 2012 (SCCM 2012). Today I will describe the deployment of scripted application installation to illustrate some differences.

As with the previous article, the goal of this is to provide a concise, straightforward procedure for deploying an application. It is important to note that since there is no single "package" for the Configuration Manager system to query, you will need to specify a lot of detailed information if you want the reporting features to reflect it accurately. That is one of the main benefits of using an .MSI or .EXE installation package.


Many businesses develop custom “applications” in-house which aren't really applications at all. For example, grouping an executable along with custom files and a custom shortcut and giving it a custom name. One that comes to mind was a Microsoft Access .MDB database file, along with an Excel Spreadsheet, and a custom shortcut which, when combined, were used for entering and tracking special mechanical parts for a construction company. The combination was referred to by all employees as something like "Parts Master" (my nickname, not theirs).

In that environment, if you tried to query computers remotely for which ones had "Parts Master" installed, you wouldn't find any. You'd find traces of Access and Excel, and maybe a shortcut file, if you looked for it. This type of installation is very commonly handled with a script, and deployed using a product like Microsoft System Center Configuration Manager. You could repackage many scripted installations into a single .MSI package using a product like Flexera Software's InstallShield AdminStudio. However, many businesses do not have such a product on-hand, or in many cases the amount of effort required to repackage them might be overkill.

For this article, I am going to deploy this bundle which the users refer to as "Parts Master". It includes a Microsoft Access Database ".accdb" file, and a Microsoft Excel ".xlsx" file. In addition, the script will adjust folder permissions on the target folder so that users can open and edit the files within it. Finally, copy/create a custom Start Menu shortcut to launch the Access database using a shortcut name of “Parts Master”.

The script language is not really that important. I chose .BAT (using a .CMD extension) since it’s one of the most common types in existence. You can just as well use a script file written in any language that will run reliably on your target devices.

Basic process

  1. Create/Edit/Test the Installation Script
  2. Create a new Application
  3. Create a Deployment
  4. Monitor the Deployment status

I’m not going to spend time on step 1 since this is really about the deployment aspects, so let's dive in.

Create a new Application

  1. Store the source files in a folder which is shared over the network. (You can only select content for making an Application deployment if it can be accessed via a UNC path reference, so drive letters are not allowed.)
    Store the source files
  2. In the SCCM 2012 Administrator Console (hereinafter referred to as the "Admin Console"), expand "Software Library" in the left-hand panel. Right-click on "Applications" and select "Create Application". You can also click the "Create" button at the top-left end of the ribbon menu, and click the "Application" sub-option.
  3. Select "Manually specify the application information", and click Next to continue.
    Manually specify the application information
  4. On the "General Information" page, fill-in the form fields to describe the application as best as you can. The more information you provide, the more it can help with future tasks. Note that this is not specifying the script itself, but rather it describes the application. When finished, click Next to continue.
    General Information
  5. On the "Application Catalog" page, specify the language and localization options. If you have online documentation to refer your users to, you can enter the URL or UNC path for providing access to it. You can also provide additional information if desired, such as Localized description, and keywords for catalog searching. Click Next to continue.
    Application Catalog
  6. On the "Deployment Types" page, click "Add".
  7. On the "General Information" page of the Deployment Type, select "Script Installer" from the "Type" drop-down list, and click "Next". Enter the Name and (optionally) Administrator comments, as well as selecting the default Language options. Click Next to continue.
  8. Specify the UNC path for the "Content Location" field, then click "Browse" to locate and select the installation script file.
    Content Location
  9. On the “Content” page, click Browse and select the script file to use for the Deployment. If you have an “uninstall” script (and you really should), specify that as well. When finished, click Next to continue.
    Content 1 Content 2
  10. On the "Detection Method" page, if you want to create a detection rule, click the "Add Clause" button, and specify the properties to tell Configuration Manager whether or not the application has already been installed on a given client. In this example, I want to check for the existence of the "hwinventory.accdb" file in the default folder path. This step is not mandatory, but it is usually a good idea to instruct Configuration Manager on how to detect custom application bundles so it can track inventory accurately. When finished, click "Next" to continue.
    Detection Method
  11. On the "User Experience" page, specify how you wish to deploy this application (per user, per device or mixed). In the example, I chose to deploy to the Device (computer), and have it install regardless of whether a user is actively logged on or not. Click Next to continue.
    User Experience
  12. On the "Requirements" page, you can specify any hardware or operating system requirements, however in this example I have no such requirements. Click Next to continue.
  13. On the "Dependencies" page, I am specifying that the client needs to have Microsoft Access 2010 installed. This is so it can properly handle opening the Access database file which is the core component of this "application" bundle. I could also specify the Access 2010 Runtime client, or even the entire Microsoft Office 2010 suite, since there is an Excel spreadsheet included. When finished, click Next to continue.
  14. Click Next to accept the confirmations and summary, and then click the Close button after the Application is created.
    Accept the confirmations
  15. Once the Application is created, click on it and review its properties to verify everything is as you expect it to be.
    Review application properties

Staging and deploying the content

The next step in the process is to make sure the installation files are placed where clients can access them when needed. Rather than repeat the same steps as in my previous article, I would rather just refer you to that for using the "Distribute Content" feature to copy the installation source content to the appropriate Distribution Point servers in your environment.

The Deployment process is the same as with a .MSI or .EXE application. You can make the Deployment “available” or “required”, as well as having it install based upon a user logon or not.

From this point, you should now have an active Deployment which clients will begin evaluating and executing, as long as they are members of the target Collection and they meet any optional Global Conditions you may have set on the Deployment.

Monitoring the Deployment

Now that the Application is in Deployment, the next step is to monitor its progress. Click on the Monitoring section in the Admin Console, and select Deployments. From here you can view the current status of each Deployment and see successes and failures. You can also drill-down into each status indicator to view more detail if needed.

Subscribe to 4sysops newsletter!


One thing I would like to strongly recommend with regards to Scripted installations is to spend a little extra time making sure that your script creates a thorough log file. A typical .MSI package will create a very detailed log file, but when you are using a script, it’s entirely up to you to handle that. The more detail you include in the log output, the better prepared you will be to troubleshoot issues that may arise during the deployment. Other than that, you should be ready to deploy!

  1. S Bradshaw 9 years ago

    FYI- entering information on Detection Method tab is not optional, which I hope they change in the future. Sometimes I use cmd files in Applications and would rather depend on the Requirements/GC instead- not forced to use a detection method.
    I’ve had to just create placeholder files just to satisfy the requested Detection Method.

  2. ssweb 9 years ago

    I agree, the Detection method is mandatory and a pain.

  3. Mark 7 years ago

    Thank for this very thorough tutorial!  In your conclusion, you note the importance of the log file.  I’d like to capture all streams to a time-stamped file name, the equivalent of adding to the command line something like:
    *> %temp%\ InstallLog-%date%-%time%.log

    Do you have any guidance on how to do that in the context of SCCM?

  4. Yuki 6 years ago

    Hello, I have issues getting an application to create a shortcut on the desktop. Its an app called “anydesk” and it just doesnt show on the desktop even though it gets installed.

    I was wondering what i can do to get this applied on the desktop

    thank you

  5. Dario (Rank 1) 6 years ago


    I have this application called “Envision” and it returns an error 0x87D00324 (-2016410844) when trying to install.

    Envision gave me a .EXE file – so my detection method is pretty simple:

    Setting type: File System

    Type: File


    File or folder name: Envision

    Additionally, it is very bizarre the fact that it launches the application during the installation process, then SCCM client says “Failed installation” and there is no folder or file installed on the computer.

    installation program: envision.exe /s

    uninstall program: “%LOCALAPPDATA%\Envision\Update.exe” –uninstall 

    What do you guys think about this?

    Thank you!

    • Leldance 5 years ago

      Dario – it depends upon the user context. Try using a detection method other than the localappdata.

      It’s not bizarre at all – apps can install fine and still return a failure to SCCM because the application creator hasn’t set the detection method correctly (in the nicest possible way!). What is happening here is that post install, when the client attempts to detect if the application has met the detection method set, nothing is being found under your localappdata\envision location.

      Equally a quick search on your error code wioll tell you the same thing over and over again. The software has installed successfully but SCCM has failed to detect it.

      It’s not a SCCM issue though!

  6. Craig 5 years ago

    I performed these steps to a tee, but when my task sequence gets to the Install Application step, it’s acting like it’s installing and after logging in, it’s not installed. Where can I look to troubleshoot this?

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account