Archive for the ‘SCCM’ Category

The SCCM 2012/R2 Application Catalog provides a request/approval capability to facilitate the distribution of applications that require approval due to licensing cost or other reasons.  Unfortunately, this function is only exposed within the SCCM console and does not provide any notification capability for pending approvals. As a result, widespread use of approvals within an organization can be challenging to implement as IT team members responsible for SCCM, who are already overloaded in many cases, are required to regularly check the console to provide reasonable turnaround on requests and must do the research themselves to determine if the request should be approved or denied.

Luckily there is a solution to this problem that is not only simple to implement, quite flexible but also free. The solution is provided by Coretech, a respected System Center solution provider based in Denmark. We have successfully used Coretech’s Application Email Approval Tool in multiple environments to provide email notification for pending and completed requests as well as provide a flexible framework to manage the approval or denial of the request.

The solution, available here: http://blog.coretech.dk/kea/coretech-application-e-mail-approval-tool/, is typically installed directly on a primary site server and has not been seen to cause any conflict with normal primary site server operations.  Note that it can be installed on a dedicated server which does require a more complex security configuration.

The article linked above describes the installation and testing process as well the ways to use it in a way that suits the specific environment. While it does not cover every conceivable scenario, it can handle several core scenarios and use cases quite well:

  • Notification for pending approvals – the most basic scenario allows IT departments to designate individuals responsible for application approvals and use the CoreTech tool to provide notification to those individuals.
  • Manager approval – another common scenario which distributes the approvals throughout the organization to the person most qualified to determine what a user requires and also responsible for the cost of licenses used by their group – the user’s direct manager (as defined in Active Directory).
  • Purchasing agent approval – in many organizations, the only required approval is that of the purchasing group who must ensure that copies of software in use are licensed and licenses are managed as mandated by each vendor.

The solution supports additional granular control including individuals who are automatically approved for all software (useful for IT or QA staff tasked with testing and deploying the applications), a fallback address in case the user’s manager is not defined in Active Directory, as well as combinations of the above scenarios – a common one being manager based approval with purchasing/license manager based notification.

Approvals, or rejections, and request tracking are provided using a separate IIS web site that is deployed as part of the solution and the solution leverages native SCCM functionality to provide auditing of approvals as well as maintain all other SCCM security controls. In addition, the tool provides customizable email templates for notification emails sent to the approvers as well as the requesting user once the application has been approved or denied.

While it is not rare to find specific components within Microsoft products that are missing key functionality needed by most clients, it is extremely rare to find an elegant and low-cost solution to address the problem. This is one of those rare solutions.

This post was created in collaboration with Greg Rhodes and Rand Morimoto.

Advertisements

The complexity of a System Center Configuration Manager 2007 R2 (from here on referred to as SCCM) is significant without the addition of native mode security and Internet Based Client Management (IBCM). But if you do need to extend your systems management for clients that rarely join your network, a common requirement for an organization with a remote sales force or telecommuting workers, you’ll appreciate the functions that are delivered with the additional complexity.

One additional element that adds to the complexity is the security implication of the IBCM solution. Since Internet based systems must connect to SCCM servers that are domain members, allowing those clients to connect directly to the IIS component on the servers probably violates not only your organization’s security policy but also general security best practices (not to mention common sense). The solution? Since the authentication for those IBCM clients is two way, requiring both a client and server authentication using PKI certificates, the options are limited to publishing the solution using an ISA server. Of course, since we want to avoid single points of failure, it would typically be an ISA farm with two (or more) servers in an array.

General instructions for configuring this scenario can be found here: http://technet.microsoft.com/en-us/library/cc707697.aspx

This is where we run into a couple of complications:

Certificate deployment

The ISA servers in this scenario will act as application proxies for the SCCM connection so the clients will authenticate to the ISA server (Using their SCCM client certificates) and the ISA server will authenticate to the client (Using the SCCM server certificate that was exported and imported in each ISA server). Then the ISA server will establish the connection to the SCCM servers and authenticate to them using its own client certificate.

The complication occurs because the client certificate deployment process that is executed on each ISA server results in a unique certificate for each server and the publishing rule certificate authentication configuration requires a common certificate in an array/farm configuration.

By default, the SCCM client certificate template does not allow the certificate to be exported since that will allow anyone with 5 minutes of access to any client system to export the certificate and use it to create any number of unauthorized SCCM Internet client systems.

The solution is to make a copy of the SCCM client certificate template that does allow the certificate to be exported using the following process:

1. Open the Certificates Template MMC

2. Right click on the Configuration Manager client template and select Duplicate Template

3. Select a name for the duplicate, such as Exportable Configuration Manager client

4. On the Request Handling tab, check the box labeled ‘Allow private key to be exported’

5. Select the security tab and configure the required security

NOTE: Make sure to configure the security on the new template to restrict enrollment and auto enrollment as appropriate.

6. Click OK to save the new template

7. Open the Certificate Authority management console

8. Expand the certificate authority, right click on the Certificate Templates folder and select New->Certificate Template to Issue

9. Select the newly created exportable template.

Once the new template is deployed to the CA, use it to issue a certificate to one of the ISA servers, export the certificate and import it into all the other ISA array/farm members and it can be used on the publishing rule successfully.

Software Update deployment – WSUS

The software update deployment process, for internal and Internet based clients, uses WSUS as an update catalog. The result is that Internet based clients must access WSUS as well as SCCM components over the Internet.

The complication here is that WSUS doesn’t support client authentication at all, certificate or otherwise. Only regular SSL based server authentication is required. In an ISA published world, that means a new listener with a unique IP address/port combination.

The solution is to deploy WSUS to a custom web site on the Internet facing SCCM servers using custom ports (typically 8530, 8531 for WSUS) and configuring an ISA publishing rule for the custom ports. Step by step for the creation of the publishing rule are available here: http://blogs.technet.com/wemd_ua_-_sms_writing_team/archive/2008/10/29/how-to-configure-isa-ssl-bridging-for-the-internet-based-softare-update-point.aspx.

If you’ve already deployed WSUS to the default web site, moving it to the custom web site can be accomplished with the following command:

C:\Program Files\Update Services\Tools> wsusutil UseCustomWebSite True

And don’t forget to change the port configuration on the Software Update component in the SCCM console.

I hope these tips help someone avoid the two weeks it took me to put all the pieces together.