In the previous article (The Background) we looked at why a Self Service portal for developers wishing to submit their applications for deployment might be useful to a large multi-national organisation. The article also looked at why it was felt desirable to develop the submission process using a Web Site.
This article will look at how the requirements were addressed in the design and ultimately how the solution was built using SCCM application objects.
In the UI a developer submitting an application would have to follow specific steps in order to set up their application using the Web site. This would allow the standardisation that the client wanted in all application submissions, no matter which team in the world submitted the application.
The diagram below shows the planned flow through the site. Note the decision point on whether an application submission is intended to supersede (supersedence in SCCM is the process of upgrading/replacing existing applications) an existing application or not. This workflow helps with standardisation, new applications will have a naming convention applied to them through the web UI while superseded application would load the previous information and allow the submitting developer to change the version information. The numbers against each box are explained in more detail in a numbered list following the diagram:
The Web Site as designed above would help meet the original requirements of creating a quick, convenient way of allowing developers a way of submitting their applications into SCCM in a controlled/standardised manner.
After the developer has configured the details for a new application they can then submit the request in order for the Web Site to create the application inside SCCM. In order to fully meet the original requirements not only should the Web Site create the application but it should also deploy to test machines. The sequence in which objects inside SCCM get created is as follows:
Note: All the components referenced for creating SCCM objects are found with the Admin console, which can be installed on a separate machine to SCCM and would be needed on the machine running the Web Site. These components can be found on: C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin
A Web Site using the SCCM console API would be subject to the double hop issue. In this project the Web Site was setup to use a service account when calling the console API, rather than using impersonation. Although, if time and the environment had allowed it other options could have been considered. By using a service account objects were created in SCCM in the same security scope as that account. This meant the security scopes for application creation were tied to the one account.
The next article will provide code examples for creating the SCCM objects listed above.