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:
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:
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.