Building an SCCM Self Service Portal for Deploying Applications – Part 1 (Background)

This article is part of a series of three that documents the experience of working with a large enterprise customer which was migrating to SCCM 2012 for application deployment. The three articles are divided in the following way:

  • Background – Why the customer felt the work was needed and their specific requirements. This is suitable for those wishing to understand how the customer context and requirements.
  • Design – What design decisions were made to meet the customer's requirements, this article looks at the high level design decisions in support of the client's requirements.
  • Example Code – Examples of calling the SCCM API in order to successfully deploy an application through SCCM. This is for technical people with code examples taken from a sample application.


Project Context

The client's organisation was made up of different companies with different teams doing development all over the world. There was a significant challenge in assisting the development teams in releasing their applications onto a user's desktop. A particular concern for the organisation was the time it took to get applications ready and into test. Also it was important that releases were handled in a standardised fashion across the organisation. Ultimately maintenance of applications onto a user's desktop was seen as painful and this was creating delays in releasing new applications.


Summary of solution requirements:

  • Allow development teams in different departments, countries and time zones to submit their own applications for deployment onto the desktop.
  • Reduce the time it takes to get an application supplied as a package from the development team, into SCCM
  • Reduce the time it takes to get a supplied application from SCCM onto the desktops of test machines
  • Standardise the way in which teams can submit their applications so that they follow a defined pattern or template
  • Make the submission process as easy to use as possible, for example the different teams submitting their applications should not need to have an in depth understanding of SCCM.
  • Allow the developer to select the following during the course of their submission:
    • Dependencies – Applications the submitting application requires in order to work correctly.
    • Requirements – Requirements that need to be present on the target machine to allow installation.
    • Supersedence – Applications the submitting application is replacing/upgrading.


As the development team undertaking the project were unfamiliar with SCCM development it was important to identify what approach to use in SCCM to address the client's requirements. The client was keen to use SCCM 2012 and wanted to release programs with dependencies, or to Supersede applications that were already released. The team decided to use the applications model, although new in SCCM 2012 it appeared perfectly designed for the customer's requirements. Applications are a new way to release software to users in SCCM, this article will assume you know a little about this feature but if you need to read up you can start here. Packages which were available in SCCM 2007 were considered, but did not appear as feature rich.


One of the first considerations was what technology to use to manage the submission of a new application into SCCM itself. Initially a custom extension to the SCCM Console was considered, some information on this can be found here. This was initially seen as a good option as SCCM 2012 offers a good level of control with specific security roles controlling what users can do. There are also some good articles around on how to deploy the Console using SCCM.


Ultimately the decision was driven by the need for simplicity. In order to submit an application into SCCM the most that a developer should need is the location of their installation files. This would reduce the amount of time it would take for developer's to take advantage of the new tool that was to be created. So the feasibility of using a Website was investigated. A Website would submit applications by creating objects in SCCM via references to the SCCM console objects. The SCCM console would need to be installed on the same machine as the WebSite, while SCCM would be hosted on separate servers.


At its highest level a request would flow into SCCM in the following way:


A developer submitting their application would just need to select the location of the installation files, what other applications their application relied on, whether it replaced an existing application and any expected requirements on the target machine.

The next article will take a more detailed look at the design.

Comments (1)

  1. Jack Fetter says:

    We developed a web-based deployment portal in 2005 for SMS 2003, we've kept it in-place through SCCM 20007 and now 2012 R2. To-date we've had our level I tech's deploy over 250,000 Advertisements, saving considerable SMS Administrator time and with no need for the SCCM Console, access or training to use it. We opted for a portal design that gets the package list from the SCCM database, presents according to the OS pf the machine they are deploying to and creates a VB script for each Collection and Advertisement (the web site handles this part) which are then picked up and processed by a Daemon we coded that runs every 30 minutes on the SCCM Site Server. All of this was originally design around the scripting examples Microsoft provided for SMS 2003 and it's been working perfectly now almost 10 years running…

Skip to main content