ConfigMgrDogs

  • Network Device Enrollment Service (NDES) – ERROR_SERVICE_EXISTS

    Ran into this doozy this week while trying to re-add the NDES role services.

    The specified service already exists. 0x80070431 (WIN32: 1073 ERROR_SERVICE_EXISTS)

    image

    The fix is to ensure there are no lingering NDES configuration.

    From Regedit, delete the following key (back it up first!)

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP

    Matt Shadbolt

  • System Center Endpoint Protection for Windows Server 2003

    A quick reminder that Windows Server 2003 is coming to end of life and will be unsupported after July 14 2015 – a mere 20 days away.

    While your Server 2003 OS will continue to run it is important to note that for people using System Center Endpoint Protection (SCEP) for antivirus – definition updates will no longer be provided.

    From the Configuration Manager Team Blog: -

    “On this same date, customers using System Center Endpoint Protection or Forefront Endpoint Protection on Windows Server 2003 will stop receiving updates to antimalware definitions and the engine for Windows Server 2003. “

    You can detect operating systems with SCEP installed using Compliance Settings in Configuration Manager and reporting on the value of the following registry key.

    HKLM\Software\Microsoft\Microsoft Antimalware\EndOfLifeState

    A value of 2 means that the operating system is nearing end of life – while a value of 3 means the operating system is no longer supported by the SCEP client.

    So what can you do – not a lot unfortunately except continue to migrate applications and services residing on legacy systems. As the team blog states: -

    “We have found in our research that the effectiveness of antimalware solutions on out-of-support operating systems is limited. Given the fast pace of technology, it has become increasingly important that customers use modern software and hardware that is designed to help protect PCs and servers against today’s threat landscape.”

    Details on how you can plan for migration and tools which can help can be found here

  • Intune and Configuration Manager UserVoice Launched

    Hello All,

    Very brief post today. The ConfigMgr and Intune team has formally released their own UserVoice pages to receive feedback and bugs from customers and the field.

    https://configurationmanager.uservoice.com/

    https://microsoftintune.uservoice.com/

    For any potential bugs, we still suggest raising a Premier Support call, as these are often the fastest and most reliable way of getting bug fixes approved.

    Matt

  • Enable or Disable Incremental Collection Updates via PowerShell

    Hi Gang.

    Here is a couple of functions I’ve written to enable or disable Incremental Collection updates by Collection Name or Collection ID.

    Enable via Collection ID

    Enable-IncrementalUpdates -CollectionID PRI0000C

    Enable via Collection Name

    Enable-IncrementalUpdatesCollectionName “CU Deployment” 

    Disable via Collection ID

    Disable-IncrementalUpdates -CollectionID PRI0000C

    Disable via Collection Name

    Disable-IncrementalUpdatesCollectionName “CU Deployment” 

    I’ve also added an optional parameter to specify the Server Name, so this can be run remotely by adding the SMS Provider name to your cmdlet

    Enable-IncrementalUpdates -CollectionID PRI0000CServer PRI

    And of course it’s pipeline enabled

    Import-CSV -Path .\collections.csv | % {Enable-IncrementalUpdates -CollectionName $_.Collection}

    Here’s the code

    Edit: Thanks to our commenter below, I’ve updated the script to perform the change depending on the membership schedule setting.

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    012
    013
    014
    015
    016
    017
    018
    019
    020
    021
    022
    023
    024
    025
    026
    027
    028
    029
    030
    031
    032
    033
    034
    035
    036
    037
    038
    039
    040
    041
    042
    043
    044
    045

    function Disable-IncrementalUpdates {

     
    [CmdletBinding(DefaultParameterSetName="CollectionID")]
     
       
    Param
        (
       
    [Parameter(Mandatory=$true,ParameterSetName="collectionID", Position=0)]
        [String]$CollectionID,
        [Parameter(Mandatory=$true,ParameterSetName="collectionName", Position=0)]
        [String]$CollectionName,
        [Parameter(Mandatory=$false,ParameterSetName="collectionName", Position=1)]
        [Parameter(Mandatory=$false,ParameterSetName="collectionID", Position=1)]
        [String]$Server
        )

    if(!$server){ $server = '.'}
    $siteCode = @(Get-WmiObject -Namespace root\sms -Class SMS_ProviderLocation -ComputerName $server)[0].SiteCode
    gwmi sms_collection -ComputerName $server -Namespace root\sms\site_$siteCode -Filter "CollectionID = '$collectionID' or Name = '$collectionName'" | % {
    $collection = [wmi] $_.__Path 
    If($collection.RefreshType -eq 4) {$collection.RefreshType = 1}
    If($collection.RefreshType -eq 6) {$Collection.RefreshType = 2}
    $collection.Put() | Out-Null
    } 
    }


    function Enable-IncrementalUpdates
     {

     
    [CmdletBinding(DefaultParameterSetName="CollectionID")]
     
       
    Param
        (
       
    [Parameter(Mandatory=$true,ParameterSetName="collectionID", Position=0)]
        [String]$CollectionID,
        [Parameter(Mandatory=$true,ParameterSetName="collectionName", Position=0)]
        [String]$CollectionName,
        [Parameter(Mandatory=$false,ParameterSetName="collectionName", Position=1)]
        [Parameter(Mandatory=$false,ParameterSetName="collectionID", Position=1)]
        [String]$Server
        )

    if(!$server){ $server = '.'}
    $siteCode = @(Get-WmiObject -Namespace root\sms -Class SMS_ProviderLocation -ComputerName $server)[0].SiteCode
    gwmi sms_collection -ComputerName $server -Namespace root\sms\site_$siteCode -Filter "CollectionID = '$collectionID' or Name = '$collectionName'" | % {
    $collection = [wmi] $_.__Path 
    If($collection.RefreshType -eq 1) {$collection.RefreshType = 4}
    If($collection.RefreshType -eq 2) {$Collection.RefreshType = 6}
    $collection.Put() | Out-Null } 
    }

    Happy POSHing!

    Matt

  • ConfigMgr 2012 R2 Service Pack 1 or Service Pack 2? Understanding Your Upgrade Options

    With the recent release of ConfigMgr 2012 Service Pack 2 and ConfigMgr 2012 R2 Service Pack 1 in preparation for Windows 10, there has been a lot of confusion arise in the community around which Service Packs are required to be applied to your environment.

    To help assist you in determining which Service Pack(s) you will need to apply in your environment, please refer to the below table.

    Before upgrading your environment please ensure you review the Planning to Upgrade System Center 2012 Configuration Manager article to ensure you meet all requirements.

     
    Starting Version Desired End Version Service Pack 2 Required R2 Service Pack 1 Required
    ConfigMgr 2012 RTM ConfigMgr 2012 SP2 Yes No
    ConfigMgr 2012 RTM ConfigMgr 2012 R2 SP1 Yes Yes
    ConfigMgr 2012 SP1 ConfigMgr 2012 SP2 Yes No
    ConfigMgr 2012 SP1 ConfigMgr 2012 R2 SP1 Yes Yes
    ConfigMgr 2012 R2 ConfigMgr 2012 R2 SP1 Yes No
    New install ConfigMgr 2012 SP2 Yes No
    New Install ConfigMgr 2012 R2 SP1 Yes Yes
     
    PLEASE NOTE:
    • If you planning on enabling R2 features as part of your upgrade by running the R2 Service Pack 1 update, please ensure you are licensed for R2 features.                
    • If you are already running R2 there is no need to run the R2 Service Pack 1 update as the R2 features will already be enabled in your environment.
     
    There are also a number of great post already published outlining the complete upgrade process - Installing ConfigMgr 2012 R2 SP1
     
    This has been a quick post and all information is provided as is.
     
  • I Wrote An App – Azure Status Alerts

    While studying for the 70-533 Implementing Microsoft Azure Infrastructure Solutions exam (of which I passed!), I found it very easy to get distracted. The major distraction was my attempt to write a very basic .NET Azure Web App.

    http://azurestatusalerts.azurewebsites.net/

    My app is a very simple one. It has three functions:

    1. Manage Subscribers

    I’m using an Azure Web App to host the .NET application. It’s a very (very) simple MVC application using scaffolding and a single controller. The controller is handling the subscribe, unsubscribe and resubscribe functions.

    The form submits the subscribers email address into an Azure SQL Database.

    image

    image

    2. Read Azure Status Updates

    Because I’m not a developer, I didn’t want to go too hard-core down the .NET rabbit hole. All I needed was a way to read the Azure Status Updates and insert the data into the Azure SQL database.

    I went with what I know, PowerShell.

    I wrote a very simple PowerShell script, that consumes the http://azure.microsoft.com/en-us/status/ RSS feed.

    Then I uploaded the script and created an Azure Webjob. Webjobs are run on a schedule (or continuously, or on-demand) and can execute a bunch of different code – bash, php, .cmd and of course PowerShell. The Webjob pulls in the information from the RSS feed, compares it with what has already been sent (to ensure no duplicates) and inserts the status into my SQL database.

    image

    3. Email Subscribers

    Once the data has been pulled from the RSS feed and inserted into my database, I then use another PowerShell Webjob to send the status alert to the subscribers list. The script uses the Send-MailMessage cmdlet, and sends the email via an Office 365 subscription I have.

    image

    The resulting email includes the status alerts title, it’s published time/date and the content of the status alert

    image

    So there it is, a very (very) simple Azure Web App written by a ConfigMgr engineer with very little development experience. If I can write something like this, jump into your MSDN subscription and use your free Azure compute hours to have a crack yourself!

    Matt

  • The Ultimate Intune Setup Guide – Stage 5: Enrol Your Devices (Windows 8.1)

     

    Now that we’ve got our ConfigMgr and Intune environments speaking nicely to each other, we can start to enrol some devices.

    I’ve previously enrolled Windows Phone 8.1, iOS and Android devices. I finally wanted to show that you can also enrol a full Windows 8.1 installation.

    First, logon to your Windows 8.1 machine and open the Windows Store

    image

    In the search box, search for Company Portal

    image

    Find the Company Portal app and install it

    image

    image

    image

    Once installed, launch the Company Portal app

    image

    image

    You’ll be prompted to enter your domain credentials

    image

    As we’re using ADFS, the logon process will redirect you to your on-prem ADFS server

    image

    Now enter your password

    image

    image

    Once you’ve logged in, you’ll be reminded to enrol your device prior to applications being made available

    image

    Now browse back to the Desktop, and open the Change PC Settings modern settings menu

    image

    Browse into the Network subset

    image

    And select Workplace

    image

    Enter your User ID and press the Turn on button to start the enrolment process

    image

    The device enrolment will lookup your enrollment services based on the username you’ve entered

    image

    And will prompt for your domain credentials. You can see here it’s utilizing our ADFS server for logon.

    image

    Agree to the terms of service, and press Turn on

    image

    Once this has been completed, the Turn on button will change to a Turn off button.

    image

    Now launch the Company Portal from your Apps menu

    image

    image

    And we can now see that we’re enrolled and my current devices are listed!

    image

    Finally, we can see the client appear in the ConfigMgr console

    image

  • The Ultimate Intune Setup Guide – Stage 5: Enrol Your Devices (Android)

     

    Now that we’ve got our ConfigMgr and Intune environments speaking nicely to each other, we can start to enrol some devices.

    We’ll enrol a Windows Phone 8.1, an iOS Device and an Android Device.

    Android Enrollment

    Android enrollment is almost as easy as enrolling your Windows Phone 8.1 device.

    First, start by opening the Google Play Store

    image

    Search for Company Portal, like iOS it should be the first result. Select the Company Portal app from the search

    image

    Press the Install button and Accept the warning about what services the client can access

    image Screenshot_2015-04-09-18-07-45

    Once it’s downloaded and installed, press the Open button to launch and configure

    image

    Press the Next button to start enrolling your device

    image

    Enter your credentials and the logon process will redirect you to your ADFS logon

    image image image

    The Android device will begin to enrol. Select Activate when prompted to accept the Activate device administrator

    Screenshot_2015-04-09-18-09-28 image Screenshot_2015-04-09-18-09-48

    Accept the Privacy Policy for the Samsung Knox services

    image

    And your device should now be successfully enrolled!

     Screenshot_2015-04-09-18-11-32 Screenshot_2015-04-09-18-12-27

    And to confirm, we should now have this device appearing in ConfigMgr

    image

  • The Ultimate Intune Setup Guide – Stage 5: Enrol Your Devices (iOS 7)

     

    Now that we’ve got our ConfigMgr and Intune environments speaking nicely to each other, we can start to enrol some devices.

    We’ll enrol a Windows Phone 8.1, an iOS Device and an Android Device.

    Apple iOS 7 Enrolment

    In this scenario, an end user is going to enrol their own device. We can use the Apple Device Enrollment Program (DEP) or the Apple Configurator tool to perform this for bulk corporate-owned devices, however this guide will not describe that process. I’ll write another post explaining these two techniques.

    From your iDevice, launch the App Store app

    image

    In the Search field, search for “Company Portal”. The first result should be the Microsoft Intune Company Portal

    image

    Press the GET button and it will begin to download and install

    image

    image

    Now find the Company Portal app and launch it

    image

    You’ll be prompted to login. Press Sign In

    image

    As we’re using ADFS, we need to add our username and then select the password field. The login process will then redirect us to our internal ADFS server to process the logon request. Enter your password when redirected to your organizations login prompt

    image image image 20150408_000459000_iOS

    After login is successful, you’ll be asked to Enroll your device

    image 20150408_000603000_iOS

    The screen will then jump to the iOS internal management profile installation process. You can see here that the Verified profile is for Mattslabs, and it is signed by the Microsoft Intune service IOSProfileSigning.manage.microsoft.com.

    To continue, press the Install button, and confirm when asked to Install Now

    image image

    The process will setup all requirement management services and certificates

    20150408_000643000_iOS 20150408_000626000_iOS

    And will ask for one final confirmation. Press Install and Done when complete

    image image

    The Company Portal app will then re-focus, and will enrol the device

    image 20150408_000752000_iOS

    You will now have access to Apps and Device Information

    20150408_000802000_iOS 20150408_000848000_iOS 20150408_000811000_iOS

    And just to confirm, the device should now appear in Configuration Manager

    image

  • The Ultimate Intune Setup Guide – Stage 5: Enrol Your Devices (Windows Phone 8.1)

     

    Now that we’ve got our ConfigMgr and Intune environments speaking nicely to each other, we can start to enrol some devices.

    We’ll enrol a Windows Phone 8.1, an iOS Device and an Android Device.

    Windows Phone 8.1 Enrolment

    On your Windows Phone, display all apps and select Settings

    image

    Under the default System view, select Workplace

    image4

    In the Workplace settings, select Add Account

    image8

    Add your Intune synchronized account, and press Sign In

    image12

    image16

    You’ll see the sign in screen notify you “We’re looking for your settings…”

    image19

    If you’ve got your ADFS setup correctly, you’ll be redirected to your on-prem ADFS servers. If you’re using password hash sync, you’ll be redirected to the Azure AD login prompts.

    Enter your password and press Sign in

    You’ll get confirmation of the account being added. Select the box to Install company app so you can install our Windows Phone app and press done

    image6

    You’ll be presented with a screen confirming the enrolment

    image10

    Finally, lets check the ConfigMgr console and we should see our Windows Phone 8.1 device

    image14

  • The Ultimate Intune Setup Guide – Stage 4: Enable ConfigMgr 2012 R2 Management

     

    Now that we’ve setup our Intune cloud services, it’s time to integrate the service with our on-prem Configuration Manager 2012 R2 hierarchy.

    In my lab environment, I’ve got a single Primary Site with all roles installed on the one site server. In a multi-tier hierarchy, the Intune connector roles can only be installed at the CAS site.

    1. The first thing we’ll want to do is ensure all of our prerequisites are met. If you’ve followed my previous three posts (here, here and here) you will already have Intune setup, public domains added and user accounts being synchronized. There are some outstanding steps to get our clients to work with ConfigMgr

      Create required DNS entries

      Our enterprise Mobile Device Management (MDM) clients will automatically look for their management services via a public URL during registration. This URL is EnterpriseEnrollment.<Your Company>.com

      In my lab scenario, that would be EnterpriseEnrollment.mattslabs.com

      As we want these devices to speak via Intune for management, we need to redirect the DNS requests via a CNAME record to the Microsoft Intune management services.
      1. Open your public DNS management tools. In my example my domain is hosted with GoDaddy, so I’m using their DNS management console

        image

        You can see here I’ve got my ADFS A record defined and the TXT record required for domain verification from this post
      2. Create a new CNAME record, name it EnterpriseEnrollment and target it at manage.microsoft.com

        image4
      3. Save your zone file and wait until the record is replicated

        image8
      4. You should eventually be able to ping EnterpriseEnrollment.mattslabs.com which will now resolve to manage.microsoft.com

        image11
    2. The second requirement is the certificates needed to push software to devices. In my lab I plan to manage Windows Phone, Android and iOS devices.

      1. Acquiring the Windows Phone certificate.

        To side-load software onto Windows Phone devices via Intune, a Symantec Code Signing Certificate is required. These certificates must be purchased directly from Symantec. http://www.symantec.com/en/au/code-signing/windows-phone/

        As I’m not willing to spend a few hundred dollars on my lab, there is a handy tool available for lab scenarios called Support Tool for Windows Intune Trial Management of Windows Phone. You can download it from https://www.microsoft.com/en-us/download/details.aspx?id=39079 

        Download this MSI and leave it for later. In the next post (Stage 5), I’ll explain how to get the Support Tool working.
      2. Acquiring the iOS Apple Push Notification certificate

        To manage and deploy to iOS devices, you must have an Apple Push Notification (APN) certificate.

        Open your Configuration Manager Console, and browse to Administration > Overview > Cloud Services

        Right-click on Windows Intune Subscriptions and select Create APNs certificate request

        image27

        Set a path for the Certificate Request to be saved to

        image39

        When prompted, add your Intune Administrator credentials and press Sign in



        Once complete, close the window and browse to the location of the saved .csr file

        image43

        Browse to the Apple Push Certificates Portal http://go.microsoft.com/fwlink/?LinkId=269844 

        Sign-in or create an Apple ID

        image15

        Click on Create a Certificate



        Accept the EULA



        On the Create a New Push Certificate page, select the Choose File button and select the .csr file previously generated

        image51

        Click Upload

        image55

        After the success confirmation dialog, click the Download button to download your APN Certificate

        image59

        Hold onto this file for later

        image63
    3. Next, we can start to configure Configuration Manager. Open the Configuration Manager Console, browse to Administration > Overview > Cloud Services

      Right-click on Windows Intune Subscriptions and select Add Windows Intune Subscription

      image67

      You’ll be prompted with the Create Windows Intune Subscription Wizard

      1. Press Next to start the Wizard

        image71
      2. Click the sign-in button and enter your Intune Administrator credentials

        image75

        You’ll be prompted to confirm the ownership of the Intune MDM capabilities. Essentially, if you want to use Intune for MDM, it either has to be via the Intune Web console, or via the Configuration Manager console. It is one or the other, never both.

        Tick the check-box and press OK

        image79

        image83
      3. In the General Configuration, configure the user Collection in which you want members to have the ability to enrol their devices, some Company Branding and also the Configuration Manager Site Code in which any devices enrolled will become a member

        image91
      4. Tick the Android and iOS support buttons, and if you have a Symantec Windows Phone certificate, select Windows Phone 8

        image95

        Note: For those who are going to use the Support Tool for Windows Intune Trial Management of Windows Phone to test the Windows Phone management, don’t enable the Windows Phone 8 management. We’ll do this via the tool in my next blog post (Stage 5)
      5. Select the Apple APN certificate created earlier

        image99
      6. Provide some contact details for your users to see in the Intune Portal

        image103
      7. Add your Company Logo (if required)

        image107
      8. Complete the wizard

        image111
    4. To complete the installation process, we finally have to add the Windows Intune Connector site system role. To do this, open the Configuration Manager Console, browse to Administration > Overview > Site Configuration > Servers and Site System Roles

      image1

      Note here we have a manage.microsoft.com server in the list. This is where you apps/etc will be stored for your MDM devices when they’re synchronized in later

      Right-click on your Primary Site Server, and select Add Site System Roles

      image5

      You’ll be presented with the Add Site System Roles Wizard
      1. Leave the General and Proxy settings default (unless you need to go through the proxy to get Internet access)

        image9image12
      2. In the System Role Selection window, select the Windows Intune Connector and press Next


      3. Press Next on the Summary screen and wait for a successful completion screen

        image19
      4. After a few minutes the role should be up and running.
    5. Finally, lets confirm that the integration and cloud sync is working. From the Configuration Manager Console, browse to Assets and Compliance > Overview > Users

      You should see all of your users listed

      image23

      Right-click on the title column, and add the column Cloud User ID



      This will add an extra column and display all of the Cloud User ID’s which has come from the Intune service. If the Cloud User ID is empty, that user will not be able to enrol their device or access any of the Intune services.

      image30

      Finally, browse https://portal.manage.microsoft.com to view your ConfigMgr Intune Branding

      image44

    We’ve now successfully configured the Configuration Manager integration with Intune.

  • Enable Windows Phone management via Intune without Symantec Certificate

     

    As part of my mega-post The Ultimate Intune Setup Guide, we enable the Mobile Device Management capabilities in ConfigMgr. One of the supported devices that we didn’t enable was the Windows Phone 8.1 management. The reason for this is the requirement of the Symantec code signing certificate, which needs to be purchased before we can manage these devices.

    To enable the Windows Phone 8.1 management in your test and demo labs, you can use the Support Tool for Windows Intune Trial Management of Windows Phone.

    https://www.microsoft.com/en-us/download/details.aspx?id=39079

    Download the executable from the site and run the installer

    image

    image

    Agree to the EULA and press Next

    image

    The default installation path will be C:\Program Files (x86)\Microsoft\Support Tool for Windows Intune Trial management of Windows Phone\

    image

    Confirm the installation was successful

    image

    Now create a Windows Phone Application using the XAP file extracted during the MSI install.

    Browse to C:\Program Files (x86)\Microsoft\Support Tool for Windows Intune Trial management of Windows Phone\SSP and copy the SSP.XAP file into your ConfigMgr Application Source

    image

    Open the Configuration Manager Console and browse to Software Library > Overview > Application Management > Applications

    Right-click Applications and select Create Application

    image

    In the Create Application Wizard, perform the following

    Add the .XAP path and select the Windows Phone app package (*.xap) from the drop down menu

    image

    The wizard should automatically pick up the Apps details and create the Application

    image

    image

    image

    Now add the Application to the manage.microsoft.com Distribution Point, so that the app content will be available to your clients

    image

    image

    image

    image

    image

    image

    Now Deploy the app to your cloud enabled users

    image

    image

    image

    image

    image

    image

    image

    image

    Next, we need to enable the management of Windows Phone devices

    Open a Command Line as Administrator and change directory to C:\Program Files (x86)\Microsoft\Support Tool for Windows Intune Trial management of Windows Phone\Support Tool\

    image

    image

    Run the following command, replacing pri.mattslabs.com with your top level ConfigMgr server

    cscript ConfigureWP8Settings_Field.vbs pri.mattslabs.com QuerySSPModelName

    image

    Now run the same script using the Model Name, this time using the SaveSettings parameter

    cscript ConfigureWP8Settings_Field.vbs pri.mattslabs.com SaveSettings ScopeId_ACB5D0B6-FDC7-459B-9BF3-A75D7E3F5B8D/Application_73602d66-47a6-4ab2-b069-8b5201c91091

    image

    Finally, enable Windows Phone 8.1 Support via the Extensions for Windows Intune

    Browse to Administration > Overview > Cloud Services > Extensions for Windows Intune

    Right-click on Windows Phone 8.1 and select Enable

    image

    Refresh until the extension becomes Enabled

    image

    The application will now be installable on your Windows Phone devices.

  • The Ultimate Intune Setup Guide – Stage 3: Sync accounts from on-prem

     

    So far in this series, we’ve signed up to the Intune service and configured our public domain. In this post we’ll sync our on-premises Active Directory accounts to the Azure AD instance that Intune will use. This allows our users to logon to their Intune based services with their corporate credentials. I highly suggest that you enable these features, otherwise the user experience of having a separate username and password for Intune will not be good.

    Now, just to confuse things, there are generally two scenarios in which this has to be configured in different ways. I’m going to cover both.

    1. No on-prem Active Directory sync to the cloud* is currently in place
    2. Some form of Active Directory sync to the cloud* is currently in place

    * by cloud, I mean anything that might use DirSync such as Office 365, Dynamics Online, Azure AD, etc

    To confuse things even more, we have multiple options for Single Sign-On (SSO)/Same Sign-On (SSO) end user experience. I’m going to cover both, too!

    1. Password hash sync to Azure AD enabling Same Sign-on
    2. On-prem Active Directory Federation Services (ADFS) performing the authentication for Single Sing-On

    Note: A quick word on DirSync vs Azure AD Connect vs Azure AD Sync

    DirSync and FIM (Forefront Identity Manager) have long been the tools used to sync on-prem AD with cloud based services. While both tools have been around for a long time and are well known, there are some disadvantages to using them. DirSync for example doesn’t play well in multi-forest environments. While FIM does a great job in multi-forest environments, it is a large product and has quite a steep learning curve.

    The AD team have released a two new tools which replace the DirSync functionality.

    Azure AD Sync is a supported product that performs most of the functions of traditional DirSync, but adds extra functionality such as mutli-forest support and password write back. It is recommended to use the Azure AD Sync tool. You can download the public release from here

    Azure AD Connect is currently in Connect Preview and is not supported. It has many of the same features as DirSync and Azure AD Sync (in Preview), and has plans for many other features such as non-AD LDAP support and extended writeback support. You can download the Connect Preview from here

    For a full feature comparison across all four directory integration tools, please see the following MSDN page

    https://msdn.microsoft.com/en-us/library/azure/dn757582.aspx 

    If you plan to use the Azure AD Connect or Azure AD Sync tool for your directory synchronization, just replace all of my steps that include DirSync with the new tools.

    New on-prem Active Directory sync required

    Your first decision to make is how you’d like your users to logon using their corporate AD credentials. There are two ways we can achieve this.

    1. Password hash sync to Azure AD enabling SSO

    This is by far the easiest option. By enabling password hash sync, your users can logon using their corporate AD username and password. The service works via syncing a double hashed password (hashed once in your AD database, and a second hash via the DirSync tool) into the Azure AD cloud identity service. When the user logs on, the password is hashed and compared to that stored in the Azure AD service. If the hash matches, authentication is successful.

    2. Authentication redirect via Active Directory Federation Services (ADFS)

    ADFS is a secure way to redirect an authentication request to a locally managed server. Corporations install and configure their own ADFS infrastructure which handles the authentication requests. When a user attempts to logon to their Intune service, the authentication request is redirected to the corporately managed ADFS servers which perform authentication against the on-premise Active Directory.

    While ADFS is seen as slightly more secure than password hash sync, the management and cost overhead is often outweighs the small security increase. ADFS is also the only way to provide a true Single Sign-On experience.

    1. Password hash sync to Azure AD enabling SSO

    Enable Active Directory synchronization in Intune

    Go back to the Users subheading, find the Active Directory synchronization: Set up option and click Setup

    image

    You’ll then be given a page with six steps to enable Active Directory sync.

    I’ve done the reading, so you don’t have to! (though it probably is a good idea to read each through)

    1. Prepare for directory synchronization
      1. Review object limits – 300,000 sync objects for a verified domain
      2. Review requirements for DirSync – Windows Server 2008+, joined ot the domain, .NET 3.5 SP1 and Windows Powershell
      3. Review requirements for domain controllers – Windows Server 2003+, Windows Server 2003 forest functional mode
      4. Ensure you have administrator permissions – local admin on the sync server and sufficient AD permissions
      5. Add alternate UPN suffix to AD – your users UPN suffix needs to match the domain you’ve added previously. This wont be required in most circumstances, however it’s a major reason for issues with the Intune service. Be sure your users UPN suffix matches the activated domain or your users can’t login!
    2. Verify domains – ensure the domains are verified as previously posted
    3. Activate Active Directory synchronization

      image

      image

      This step will enable the AD synchronization features across the entire tenant you manage

      image

      You’ll receive confirmation that Active Directory synchronization is enabled
    4. Install and configure the Directory Synchronization tool

      image

      We’re now prompted to download and install the DirSync tool. This is the agent that will run on a schedule and upload your directory objects into the Azure AD cloud service. Download and install this on your designated sync server.

      1. When prompted by Internet Explorer, save the dirsync.exe file

        image

      2. Once downloaded, run the executable. It will extract the files and give you the installation UI

        image
      3. Click Next when prompted to start the setup

        image

      4. Accept the EULA and select Next

        image

      5. Target the installation to wherever you desire. I’m leaving it as the default C:\Program Files\Windows Azure Active Directory Sync. Click Next

        image

      6. Installation will then automatically start

        image

      7. Once complete, click Next

        image

      8. You’ll then be given the opportunity to run the Configuration Wizard. Select it and press Next

        image

      9. On the Windows Azure Active Directory Sync tool Configuration Wizard, start it by clicking Next

        image

      10. Enter your Intune tenants credentials and select Next

        image

      11. Enter your local Active Directory credentials

        image

      12. You’ll then be asked if you would like to enable a “Hybrid Deployment”. Hybrid Deployment allows attributes to be synced BACK from Azure AD into your locally stored Active Directory.
        Intune does not require a Hybrid Deployment, so don’t select this option

        image

        For more information, and a list of the objects that can be written back, please see these links:

        https://technet.microsoft.com/en-us/library/hh967642.aspx

        http://social.technet.microsoft.com/wiki/contents/articles/19901.dirsync-list-of-attributes-that-are-synced-by-the-azure-active-directory-sync-tool.aspx#Table_2_Attributes_that_are_written_back_to_the_on-premises_AD_DS_from_Windows_Azure_Active_Directory_in_an_Exchange_hybrid_deployment_scenario 

      13. As discussed earlier, the easiest way to provide an SSO experience is with Password Sync. To enable Password Sync, select the check box Enable Password Sync and press Next

        Note: If you plan on using ADFS, you want to disable this setting.

        image

      14. The wizard will then configure your DirSync services and notify you when complete


        image

        image

        NOTE: I was getting the following error when running this from my Domain Controller

        System.Management.Automation.CmdletInvocationException: A constraint violation occurred

        We don’t suggest that you run the DirSync tool from a Domain Controller, however we do support it. The trick to overcome this error is to logoff and logon before running the configuration wizard.
      15. Finally, select Synchronize your directories now and select Finish

        image

    5. Verify directory synchronization

      1. Check the event logs of the synchronization server for sync start and stop events
      2. View your synchronized users from the Users view in the Account Portal

        image

        Note: the important part is the UPN for each user
    6. Activate Synchronized users – once you’re synced users appear, you need to activate the users on the Intune side. This is essentially assigning the users a license to use the Intune service. Note that for each activated user, a license fee may be required.

      Select all of the users in which you want to enable Intune access, and select Activate synced users

      image


    7. Finally, test the SSO experience by logging in with a test users account. Open an new Internet Explorer sessions using InPrivate Browsing

      image
    8. Browse to http://portal.manage.microsoft.com and enter your Domain credentials

      image
    9. You should be presented with a custom Organizational Intune portal page.

      image

     

    2. Authentication redirect via Active Directory Federation Services (ADFS)

    If your organization requires true Single Sign-on and does not want to sync password hash to the cloud, the second option is to use ADFS. If your organization already has ADFS configured for other services, the majority of the work is already completed. If you don’t have ADFS, you should consult your AD team as it’s likely they’d be the ones installing the service.

    For this guide though, I’m going to install the ADFS services in the most simple manner to ensure our Intune users can logon using their corporate AD credentials.

    Start by logging into the http://account.manage.microsoft.com page, and selecting Users. This time we’re going to select Single sign-on: Setup

    image

    From this page, we’ll have 10 steps involved in configuring SSO. Again, I’m going to do all the hard work for you!

    1. Prepare for Single Sign-on
      1. Ensure Active Directory is running in either Windows Server 2003 R2, 2008, 2008 R2, 2012 or 2012 R2 and has a functional level of mixed or native mode
      2. Decide on your ADFS service design – for example, are you going to have an ADFS Proxy?
      3. If you plan to use Shibboleth Identify Provider, install and prepare it
      4. Install any required Windows Updates - https://technet.microsoft.com/en-us/library/hh967624 
    2. Plan for and deploy Active Directory Federation Services 2.0
      1. In my environment, I wanted to have ADFS running on a separate server. As it’s an Azure Virtual Machine, it’s quite easy for me to publish a public endpoint so that the server will be publically available for the Intune service to use it for authentication.
        In your environment, it may be configured differently.
      2. Firstly, as the server is going to be publically accessible, we need to secure the communications with an SSL certificate. Our ADFS configuration later will ask us to choose the required certificate, so lets get it ready now.
        I’ve got a wildcard certificate provided by the Digicert Certificate Authority (CA)

        image
      3. From your CA, download the public certificate. Open the Certificates MMC by going Start > Run > mmc

        image

        File > Add/Remove Snap-in…

        image

        Select Certificates and press Add

        image

        Select Computer account and press Next

        image

        Select Local Computer and press Finish

        image
      4. In the Certificates MMC, expand Personal > Certificates

        image
      5. Right-Click Certificates, and select All Tasks > Import

        image
      6. In the Certificate Import Wizard, press Next to get started

        image
      7. Browse to the CA provided certificate and press Next and then Finish

        image
      8. You’ll then have the certificate stored in the Personal certificate store, ready for use with ADFS

        image
      9. Now, to install the ADFS role. On the new server, open up Server Manager, select Manage and click Add Roles and Features

        image
      10. Next, Next, Next through the wizard until you come to the Server Roles section

        imageimageimage
      11. Select the Active Directory Federation Services role and select Next

        image
      12. Leave the Features selection as it is, and press Next. You’ll be prompted with an ADFS confirmation screen, press Next to continue. Finally, press the Install button to install the ADFS role

        imageimageimage
      13. Once the role has been installed, select the Warning message in the Server Manager console. You’ll see a button to Configure the federation service on this server. Click that to launch the configuration wizard

        image
      14. Select the Create the first federation server in a federation server farm from the radio boxes, and select Next

        image
      15. As I’m running the installation using my Domain Admin account, I don’t need to specify a user. If you are running this with a restricted account, you’ll need to provide an account with Domain Admin permissions to configure ADFS

        image
      16. Select the SSL Certificate we imported earlier, set the Federation Service Name to the name of the server you’re hosting ADFS on, and set a Federation Service Display Name and press Next

        image
      17. Specify a Service Account which will run the ADFS services

        image
      18. In most environments, you’ll want to use a Windows Internal Database. In larger environments, you may want to store the ADFS configuration in a SQL Database instead

        image
      19. Review Options, confirm Pre-requisite Checks were successful and press Configure to setup the ADFS services.

        image image
    3. Install the Microsoft Online Services Module for Windows PowerShell
      1. To create the trust relationship between your on-prem ADFS server and the Microsoft Intune service, you need to install the Microsoft Online Services Module for Windows PowerShell. These are a set of PowerShell cmdlets that will allow you to configure Single Sign-On
        Before installing the PowerShell module, you need to install the Microsoft Online Services Sign-In Assistant v7.
      2. Download the Microsoft Online Services Sign-In Assistant v7 from http://www.microsoft.com/en-au/download/details.aspx?id=41950 and run the installer

         image
      3. The installer will quickly complete

        image

      4. Now download the 32-bit or 64-bit version of the Microsoft Online Services Module for Windows PowerShell via the http://account.manage.microsoft.com page

        image
      5. Run the installer

        image
      6. Click Next on the installer splash screen, Accept the Terms and select a location for the installation to be installed to
      7. Click Install and confirm the installation was successful

        image
    4. Verify additional domains
      1. Browse to the Domains tab in the http://account.manage.microsoft.com portal and confirm your domain is Verified

        image
    5. For 5. Prepare for directory synchronization, 6. Activate Active Directory synchronization, 7. Install and configure the Directory Synchronization tool, 8. Verify directory synchronization and 9. Activate synchronized users, follow the steps provided when configuring the Password Hash sync above.
    6. The final step, Verify and manage single sign-on is a little vague, as we actually haven’t completed all of the steps required.

      image 

      Before our Single Sign-On is working, we need to setup a trust relationship between the on-prem ADFS server and Microsoft Online
      1. All the required information can be found at https://technet.microsoft.com/en-us/library/jj205461

        On your ADFS server, Open the Microsoft Azure Active Directory Module, by browsing Start > Programs > Windows Azure Active Directory and run the console as Administrator

        image
      2. Store your Intune Administrator credentials into a variable for later use, by typing

        $cred = Get-Credential

        Supply your credentials when prompted

        image
      3. Next, connect to the Microsoft Online Service by typing

        Connect-MsolService –Credential $cred
      4. Set the ADFS server configuration by entering (note: if your Azure AD PowerShell module is installed and running on the ADFS server, you don’t need to perform this step)

        Set-MsolAdfscontext –Computer adfs.mattslabs.com

        You’ll be prompted for credentials. These are your domain credentials.

        image
      5. You now have two choices. First is to setup the Federated Domain if you have not configured Azure AD SSO with password hash sync. The second option is to convert a previously configured Azure AD password hash sync into a ADFS Federated SSO
        1. If you haven’t configured Azure AD Password Sync previously, run the following commands to setup the federation

          New-MsolFederatedDomain –DomainName mattslabs.com

          You’ll be prompted to create a DNS record to verify that you own the domain

          image

          As per my previous steps, create the DNS TXT record.
        2. Once the domain is authorized, re-run the following command to complete the configuration
          New-MsolFederatedDomain –DomainName mattslabs.com

        1. If you have previously configured Azure AD Password Sync, instead of setting up a new Federated Domain, we need to convert the domain from a Standard Authentication Domain into a Identity Federation Domain

          Convert-MsolDomainToFederated –DomainName mattslabs.com

          image
      6. Finally, you should verify that your ADFS instance is working correctly. Perform the following steps
        1. Check your ADFS server is publically available.

          From an external address, ping your ADFS server and ensure it resolves correctly

          image

          From a web browser, browse the ADFS URL https://adfs.mattslabs.com/adfs/ls

          image

          Browse to http://portal.manage.microsoft.com, enter your on-prem credentials

          image

          If ADFS is working, when you tab to the password box it should redirect you to your ADFS instance

          image

          And prompt for your domain credentials

          image

          Finally, you can see the ADFS redirection and authentication happening if you watch the browser path closely

          image
      7. And we’re in!

        image

    Active Directory sync already configured

    If you’re using one of the many Microsoft cloud platform applications such as Office 365 or Dynamics Online, it’s likely you’ll already have DirSync configured and synchronizing your on-prem directory with the Azure AD service.

    If this is the case, the majority of the work has been done for you!

    In my Intune Users console view, there are currently no users, other than my service administrator accounts.

    image

    1. Verify that Active Directory sync has been configured. You’ll need to speak with whoever configured the first instance of DirSync for your organization. Have them logon to their Azure AD console and display the domain configuration.
      1. Browse to https://manage.windowsazure.com
      2. In the Azure management portal, find the Active Directory node and select it

        image
      3. In the Active Directory node, you should see your organizations domain has been synced and it’s status is Active

        image
    2. Verify that your domain has been added to Intune. From the https://account.manage.microsoft.com console, select Domains and confirm it has been added and authorized. If your organizations domain does not appear, follow the instructions from my previous post on adding your managed domain.

    3. Enable Active Directory synchronization by browsing to Users, and pressing the Set up link

      image
    4. It’s a bit confusing here, because we’re not really setting up AD Sync, rather we’re associating a previously configured AD Sync with our Intune tenant.

      Because DirSync and/or ADFS,  has been configured previously, we can skip to step 3 and just activate the Active Directory synchronization

      image

      When prompted, press Activate

      image

      Step 3 will return success when this is completed

      image
    5. Now either wait for DirSync directory synchronization to run, or force it to run using Start-OnlineCoexistenceSync (http://www.msexchange.org/blogs/walther/news/dirsync-change-forcingmanual-syncs.html), and check the Users console. You should not have all of your synchronized users appear in Intune

      image

    We’ve now configured the Intune service to use your on-prem Active Directory accounts for logon.

  • The Ultimate Intune Setup Guide – Stage 2: Configure Your Public Domain

    We started The Ultimate Intune Setup Guide by signing up to the Intune service in the previous post.  This post we’re going to configure the Public DNS required for your public Intune service to work for your clients.

    Step 1 – Add your public domain to the Azure Management Portal

    First, open your browser and visit https://account.manage.microsoft.com providing your Intune Global Admin credentials.

    You’ll be greeted with the Account Portal. Select the Domains link under the Management subheading

    image

    In the Domains section

    image

    Enter your public domain

    image

    You’ll then be prompted to Verify domain. This process is required to ensure that the public domain that you’re specifying is actually owned by you.

    The process requires you to add either a TXT Record or MX Record into your public DNS provider. Azure then checks the value that you’ve set to confirm that you do in fact own the domain, and have write access.

    image

    In my environment, I’ve got my public DNS hosted with GoDaddy, but the process is very similar across all DNS providers.

    Step 2 – Creating DNS Verification Records and Verifying

    Login to your domain/DNS provider, and find the DNS management section. You’ll want to edit the zone of the domain your users will login via

    image

    You’ll probably see a lot more records in your production DNS, but for my demo it’s a clean zone. We need to create the TXT Record as per the requested Intune Add a domain value

    image

    Add the value (the @ host name just means the root of that domain, in this instance it’s just .mattslabs.com (notice the extra period .)

    image

    image

    And you can see the TXT Record has been created

    image

    Step 3 – Verify your domain in Intune

    Now that we’ve created our DNS Record, we need to wait and verify! Firstly, DNS can take a while to update depending on your DNS hosting provider, as well as the DNS refresh interval in the Intune platform.

    If you want to perform a manual check of the records, use nslookup

    image

    Once our DNS is up-to-date, click on the Verify button to get Intune to check for the TXT Record, and verify that it matches what it is expecting

    image

    You’ll then receive a confirmation that the domain has been added successfully

    image

    And your domain will now appear in your Domains section of the Account Portal

    image

  • The Ultimate Intune Setup Guide – Stage 1: Sign-up

     

    My Configuration Manager labs have taking a massive hiding over the last 12 months, with lots of very unsupported hacks going on. I have been on some Azure training of late, and thought it would be a great idea to rebuild my Azure labs as I originally built them when Azure was in it’s infancy. Also, we now have a local Azure datacentre in Australia (yay!) so it made sense to start again with a clean slate.

    The great thing of hosting your labs in Azure, is they have public IP endpoints. This means it’s very easy for us to setup public websites/etc, and very simple to configure public services such as Microsoft Intune.

    So, as I was rebuilding my ConfigMgr and Intune environment, I thought I’d put together The Ultimate Intune Setup Guide.

    Step 1 – Sign-up for your Intune subscription

    First thing is to create your Intune subscription. For this demo, I’m going to use a trial account, but you’ll want to use an account that you plan to use long term.

    Browse to http://www.microsoft.com/en-us/server-cloud/products/microsoft-intune/ and hit the Try tab

    image

    Select the Sign up for a free trial of Microsoft Intune

    image

    IMPORTANT: If your organization is an Office 365 customer, or utilize Microsoft Cloud Services such as Dynamics Online, you should logon with the same account used to configure the previously created cloud service. This is to ensure your Intune service can access the already configured and synchronized Azure AD infrastructure.

    Enter your details

    image

    You’ll then get redirected and logged into your Intune Account Portal. Add your phone number for account recovery, or skip and Remind me later

    image

    You should now have Global Administrator access to your Intune tenant

    image


  • Associating your Intune DirSync Directory with your Azure tenant

    Cloud identity is one of the core features and benefits of using the Azure platform. Fortunately, Microsoft Intune uses the same back end to store your users cloud identities.

    This guide is for admins who have setup and configured DirSync for Intune, and want to retroactively add that synchronized domain to their organizations Azure tenant.

    First, browse to http://manage.microsoftazure.com and login using your organizations Service Administrator account.

    Note: for these steps to work, you may need to be using an MSA account (hotmail.com, outlook.com, etc). If you don’t receive the “use existing domain” option when creating your Azure AD domain, create a co-administrator with an MSA account. Login using this account and the option should appear.

    Go to the Active Directory tab. You’ll see just the default Microsoft directory is present.

    image

    Select the + New button in the bottom left hand corner

    image

    You’ll receive the New blades fly-in. Select App Services > Active Directory > Directory

    image

    The blade will expand. Select Custom Create

    image

    This will produce a pop-up to Add directory

    Select Use existing directory, and check the box for I am ready to be signed out now. When ready, click the tick in the bottom right. You’ll then be signed out and prompted for your Intune Tenant credentials.

    image

    Enter your Intune credentials

    image

    You’ll automatically be asked if you want to associate the Intune directory with your Azure AD tenant. Select Continue

    image

    Success! You can now sign out and back to your main Azure tenant

    image

    You can now see that the Mattslabs domain has been added into my Active Directory section in my main Azure tenant

    image

    Just to be sure it’s all working nicely, click on the new domain to view the users

    image

    You can see my users with mattslabs.com UPN is now in my Azure console.

    image

    You’re now good to go. In this guide we’ve successfully associated our previously synced Microsoft Intune directory into our organizations Azure Active Directory.

    Matt Shadbolt

  • Different scenarios for using Prestaged content

     

    Hi All,

    Late last year I had a request from one of my customers to look into the different behaviours of prestaged content.

    I've summarised and shown examples of the results below which will hopefully be of benefit to some of you.

     

    Scenario 1)

    If I have content already successfully distributed to a DP and I try to extract it again what will occur ?

    As long as you use the /S switch in the command line the content will be ignored if it is the same version or above.

    See the following TechNet article for command line details.

    http://technet.microsoft.com/en-us/library/988b456a-efa8-45d1-89a6-894585dfca38

    As an example for a single file we could use extractcontent /P:D:\PrestagedFiles\MyPrestagedFile.pkgx /S

    For all files in a location we could use extractcontent /P:D:\PrestagedFiles /S

    See an example from the PreStagecontent log below

    clip_image001

    And again where it shows that it doesn’t send any Status message to the servers if it is skipped..

    clip_image002

    Scenario 2) Can I extract content to a DP that isn’t marked as prestaged ?

    Yes, the content will get extracted to the DP’s content library and when you distribute that content to the DP afterwards it will simply send a message to the DP and the DP will confirm that the content sits in the content library and respond back to the Server marking it as completed.

    See logs below as an example

    We extracted the content for package PRI00030 at the DP details from the PreStagecontent log at the DP

    clip_image003

    I then distributed the package to the DP see details below in distmgr.log at the Primary

    clip_image004

    We can see it successfully added in smsdpprov.log at the DP

    clip_image006

    And again in distmgr.log we can see that its sent a completed status message back to the Primary.

    clip_image008

    Scenario 3)  What happens If I extract content that is an older version than what is available ?

    You will need to update the package at that Distribution point. See the entry below from TechNet.

    http://technet.microsoft.com/en-us/library/988b456a-efa8-45d1-89a6-894585dfca38

    clip_image009Important

    In the following scenario, you must update content that you extracted from a prestaged content file when the content is updated to a new version:

    1. You create a prestaged content file for version 1 of a package.

    2. You update the source files for the package with version 2.

    3. You extract the prestaged content file (version 1 of the package) on a distribution point.

    Configuration Manager does not automatically distribute package version 2 to the distribution point. You must create a new prestaged content file that contains the new file version and then extract the content, update the distribution point to distribute the files that have changed, or redistribute all files in the package.

     

    As you can see there are more scenarios than just a Prestaged Distribution point where you can make use of prestaged content.

  • ConfigMgr 2012 R2 Certificate Requirements and HTTPS configuration

    We have had a number of recent requests from our customers on the certificate requirements and configuration steps required to configure HTTPS communication in a ConfigMgr 2012 environment.

    I would like to give a massive thank you to Ravi Kalwani, a member of the ANZ Microsoft ConfigMgr Premier Field Engineering (PFE) team who put this guide together.

    This post contains the step-by-step configuration needed to successfully implement HTTPS communication in your ConfigMgr 2012 R2 environment.

    Creating Templates for Site Systems and Clients Certificates

    Create a template for ConfigMgr Clients

    On the issuing Certificate Authority go to Administrative Tools and Open Certificate Authority Console

    image  

     Right Click On Certificate Templates and Click Manage to open Certificate Template Console

    image

    image      
          

    Now right-click on Workstation Authentication and click Duplicate Template

    image

    Make sure to use Server 2003, not 2008

    image

    We are first creating Certificate Template for ConfigMgr client Authentication Certificate, so give the Template a Name that would related to what it would generate Certificates for, I have chosen Name “ConfigMgr Client Certificate”

    image 

    Click on the Security tab, select the Domain Computers group and add permissions of Read and Autoenroll, do not clear Enroll

    image

     Now Click on the Subject Name Tab, and Select DNS name in Build from this Active Directory information, Then click OK.


      image

     Refresh Certificate Template console to see the new template in there.

    image

    Create a template for Site Systems (MP, DP, SUP and/or WSUS)

    Still in Certification Authority, in the Certificate Templates list we’ll setup the next template. Right-click on the Web Server template, and click Duplicate. On the General tab, change the Template something more appropriate like ConfigMgr Web Server Certificate. 

    image

     Next click the Security tab, and add your SCCM server to the permissions list and add the Enroll permission.

    If you were running a SCCM configuration with multiple sites and servers, it is recommended you create a SCCM Servers Active Directory Security Group. I’ve created an AD security group called ConigMgr_Servers. So I’ve added the Group with Enroll permission. 

    image

     Now Click on the Subject Name Tab, and Select Build from this Active Directory information, and then Select DNS name. Then click OK.

    image 

    Create a ConfigMgr Client template for WinPE Images

    This step is only needed if you have all you MP/DP running in https. In this step we are creating a Client Authentication certificate that will be used to generate certificate for WinPE images, which will later contact MP and DP on Https.

    If you don’t have all MP/DPs in HTTPs you can continue to build image via Task Sequence and WinPE images will contact HTTP MP and not HTTPS

    Right-click on the Workstation Authentication template, click Duplicate. Rename the template as ConfigMgr WinPE images, I personally like to give longer validity as WinPE images can’t renew their certificate and it’s a manual process to create and Import certificates in WinPE images before the validity expires. In my lab I’ve given 5 years validity.
     
    image

     On the Request Handling tab select Allow private key to be exported. 

    image

     On the Security tab add your SCCM servers group, and give Enroll permission. Click Apply, then OK.

    image

     Now if you look at the Certificate Templates Console you will see our three new templates. 

    image

     We can now close the Certificate Templates Console. 

    Enable Certificates to be issued

    Open Certificate Authority Console-> Right Click Certificate Templates-> Select New-> Certificate to Issue   

    image 

    Select all three of the ConfigMgr templates we created then click OK.

    image

     They will then show up in the Certificate Templates listing. Once you verify that, you can close the Certification Authority console. 

    image

    Create an Auto-Enrol GPO for the Client Certificate template  

    Now we’ll need to create a Group Policy at the OU of our domain where we want client to get ConfigMgr Client Certificates and only does HTTPS with MP, DP and SUP
    Launch Group Policy Management on your Domain (Start > Administrative Tools > Group Policy Management). Right-click Group Policy Object and select New as we are going to create a new GPO and link it to OU later. Name your GPO appropriately, I have given my GPO Name “AutoEnroll ConfigMgr Client Cert“, then click OK.
     
    image
    image
     
    Edit your newly created GPO. Navigate to: Computer Configuration> Policies > Windows Settings > Security Settings > Public Key Policies. Right-click on Certificate Services Client – Auto-Enrollment and then click Properties. Change the Configuration Model: to Enabled, and check the Update certificates that use certificate templates. Then click Apply and OK.
     
    image
    image
     
    If you recall, we configured the ConfigMgr Client Certificate Template earlier and we set the permissions for Domain Computers to Read, Enroll, and Auto Enroll. Now when you run a “gpupdate /force” or in 15 minutes when GP is re-applied, any machine on the domain communicating with the DC will request and receive a client certificate automatically that will be place in the Local Computer Personal Certificate Store.

    Request Web Server Certificate on MP, DP and SUP

     Now we need to setup the appropriate certificates on our System Center Configuration Manager Management Point. The first thing you will need to do is reboot your SCCM server. This is so that it will pick up the permissions change that will allow it to register for the Web Server Certificate.

     Once the reboot completes, click Start > Run.  Type mmc.exe and click OK.  Click File > Add/Remove Snap-In, Choose Certificates and click Add.  Choose Computer Account, click Next.  Choose Local Computer, click Finish.  Click OK, and then expand the Certificates tree to the Personal > Certificates folder.

    You may notice that your SCCM server has Auto-enrolled for and received its Client Authentication Certificate we just setup. 

    image 
    Right-click in a blank space and click All Tasks > Request New Certificate, You are presented with the Certificate Enrollment wizard. Click Next
     
    image

     Leave the default on this page, and click Next           

    image
     
    Select ConfigMgr Web Server Certificate Template and Click Enroll. 
     
    image

      Once you see Status: Succeeded, Click Finish  

    image

      Now you will be able to see both all three Certificates on Certificate Console of Site Server  

    image

    Now we need to export the Client Distribution Point Certificate while we are in the Certificates Management console. Right-click the certificate that shows template name as Certificate WinPE images and click Export. 

    image

     Click next on the “Welcome to the Certificate Export Wizard


      image

      Select “Yes, export the private key”, if you see this option greyed out, you probably have wrong certificate selected.


      image

     Select “Personal Information Exchange – PCK #12 (.PFX)” and click Next


      image

      Set a password in this screen and click next, you will need this certificate while importing it to Distribution point property.

     
      image

      Select Destination where would you like to export the certificate, and give it a descriptive name.


      image

    Click Finish


      image

    Importing Certificates in IIS

    After all the certificates have been requested we need to now import the Web Server Certificate to the Default Website and WSUS Website in IIS.
    Launch IIS Manager (Start > Administrative Tools > Internet Information Services (IIS) Manager).Navigate to the Default Website, right-click it and select Edit Bindings.

    image

     Select the https binding and click Edit

      image        
            
    Select the https binding and click Edit. The select the ConfigMgr Web Server Certificate and then click OK. I highly recommend viewing your certificate afterwards, checking the Details tab, to ensure you selected the correct one.


      image

     Now do the same on WSUS Website.
    image         
    Select Appropriate Certificate (not SQL), and click OK. 

    image

      And Click Close.
      image

      Last Piece of configuration that we need to do is, manually configure five WSUS virtual directories to use SSL. The five Virtual directories are (APIRemoting30, ClientWebService, DSSAuthWebService, ServerSyncWebService, and SimpleAuthWebService)
    The Virtual directories has also been definied in the TechNet document
    http://technet.microsoft.com/en-us/library/bb633246.aspx          
             
    Putting ApiRemoting in SSL


      image

     Check the box Require SSL and Select Ignore under Client certificates
      image

     Now do the same for rest of four Virtual directories mentioned above.

    Configuring MP, DP and SUP to use SSL

     Now that we have completed all our certificates pre-requisites and ready to configure ConfigMgr Components to use SSL.  

    Configuring Management Point to use SSL

    Go to Management Point Property, (Open ConfigMgr console>Administration Workspace>Site Configuration>Servers and Site System Roles>Select Your Sever and Right Click on Management Point Role and Click Property.


      image

    Select HTTPS from the Client Connections options, this will kick off Reinstallation of Management Point, and reconfigure its Virtual directories to use HTTPS communication only.  

    image

     You can see MP Reinstallation happening in MPSEtup.log


     
    image  

    Configuration Distribution Point Role to SSL

    Go to Distribution Point Property, (Open ConfigMgr console>Administration Workspace>Site Configuration>Servers and Site System Roles>Select Your Sever and Right Click on Distribution Point Role and Click Property


     
    image

    Select HTTPS under Specify how client computers communicate with this distribution point


      image

    If you would like Clients to communicate back to DP on HTTPS even during Task Sequence than you would need to Select Import Certificate under Create a self-signed certificate or import a PKI client certificate


      image

     Click Apply, This will reconfigure this Distribution Point virtual directory to Use Only HTTPS communication

    Configure WSUS/SUP to use HTTPs

    Open up command prompt in Admin Context on WSUS server and change working directory to WSUS installation path Tools directory and run following Command

    WSUSUtil.exe ConfiguresSSL <Intranet FQDN of WSUS Server>

    image

    Go to Software Update Point Property, (Open ConfigMgr console>Administration Workspace>Site Configuration>Servers and Site System Roles>Select Your Sever and Right Click on Software Update Point Role and Click Property


      image

    Check the box Require SSL communication to the WSUS Server and Click Apply


      image

     This as well will reinstall Software Update Point Role with new settings.

    Site Server Settings

    Change your ConfigMgr setting to ensure client communicates with HTTPs Enabled MP when there is a client authentication cert is present.
    Launch ConfigMgr Console> Administration Workspace> Site Configuration> Sites> Right Click your Primary Site> Properties and Go to Client Computer Communication Tab.
    Check the box “Use PKI Client certificate (client authentication capability) when available”

    image

    Review clients that have Client Authentication Cert to make
    sure they are communicating to MP in HTTPs.

    A Client that has ConfigMgr client cert installed will see changes made to ConfigMgr Server via Published information in Active Directory, and will switch to HTTPs if it detects a Valid Client Cert Present on Computer’s Personal Store.

    image

    References

    PKI Certificate Requirements for Configuration Manager
    http://technet.microsoft.com/en-us/library/gg699362.aspx

    System Center 2012 Configuration Manager: R.I.P. Native Mode

    http://blogs.technet.com/b/configmgrteam/archive/2012/05/25/system-center-2012-configuration-manager-r-i-p-native-mode.aspx

    Step-by-Step Example Deployment of the PKI Certificates for Configuration Manager: Windows Server 2008 Certification Authority

    http://technet.microsoft.com/en-us/library/gg682023.aspx

  • PowerShell Script to Create and Link Schedules in Azure Automation

     

     

    Hi All,

    Lately I've been playing with Azure automation and needed to create schedules to kick off Runbooks at certain times of the day. Rather than doing this manually I decided to just write a simple PowerShell script to create these for me automatically, since I may need to do this task again in the future.  To do this I need to ensure I have Azure PowerShell configured and connected . I wont go into how in this blog please use the following blog as a reference How to install and configure Azure PowerShell

    I then used the following script I wrote to create and register each Schedule

     

    ################################################################################################################################

    $Days = ("Monday","Tuesday","Wednesday","Thursday","Friday")
    $StartDate = ("26/01/2015 08:30","27/01/2015 08:30","28/01/2015 08:30","29/01/2015 08:30","30/01/2015 08:30")
    $EndDate = ("26/01/2015 20:30","27/01/2015 20:30","28/01/2015 20:30","29/01/2015 20:30","30/01/2015 20:30")
    $Accountname = "yourAutomationAccountname"
    $Count = 0

    ForEach ($Day in $Days)
    {

    New-AzureAutomationSchedule -AutomationAccountName $Accountname -Name "Start AzureVMs $($Day)" -StartTime "$($StartDate[$Count])" -DayInterval 7
    Register-AzureAutomationScheduledRunbook -AutomationAccountName $Accountname -Name Start-AllAzureVM -ScheduleName "Start AzureVMs $($Day)"
    New-AzureAutomationSchedule -AutomationAccountName $Accountname -Name "Stop AzureVMs $($Day)" -StartTime "$($EndDate[$Count])" -DayInterval 7
    Register-AzureAutomationScheduledRunbook -AutomationAccountName $Accountname -Name Stop-AllAzureVM -ScheduleName "Stop AzureVMs $($Day)"

    $Count ++

    }

    ##################################################################################################################################

     

    We can see that before I run my script I have no schedules attached to my Start-AllAzureVM and Stop-AzureVM Runbooks

    image

    image

    we then run the script from which you should see a similar output to the one below.

    image

    We now can see that both of our Runbooks have Schedules created and assigned.

    image

    image

    As always if you improve or have similar scripts to share feel free to comment below.

  • PowerShell ISE Add-On to connect to ConfigMgr (Connect-ConfigMgr)

    Man, I’ve been on a PowerShell rampage lately!

    It always drove me crazy loading the PowerShell Module for ConfigMgr. First, you had to find the path of the AdminConsole\bin directory and then remember the name of the psd1 module file. Finally, you had to remember the site code of the site you normally work with.

    This post outlines a custom PowerShell ISE Add-On I’ve created to quickly load the ConfigMgr PowerShell module and connect to your console default SMS Provider location.

    image

    The first thing you’ll need to do is create a custom PowerShell ISE profile (if you don’t already use one)

    Browse to %UserProfile%\Documents and look for a WindowsPowerShell directory. If it doesn’t exist, create it. Then, look for a file called Microsoft.PowerShellISE_profile.ps1 (again if it doesn’t exist, create it). This file is automatically loaded when the ISE starts up, and is really handy for auto-loading any common functions.

    image

    Now edit the file in either the PowerShell ISE or Notepad.exe and paste in my script. If you’ve already created and customized your profile in the past, just add my script to the bottom of your profile file.

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    012
    013
    014
    015
    016
    017
    018
    019
    020
    021
    022
    023
    024
    025
    026
    027
    028
    029
    030
    031
    032
    033
    034
    035
    036
    037
    038
    039
    040
    041
    042
    ## ADDS A Connect-ConfigMgr ITEM TO THE ISE ADD-ONS MENU ##
    ## Created by Matt Shadbolt - http://blogs.technet.com/b/ConfigMgrDogs ##


    Function Connect-ConfigMgr {

    $CustomError = $null 

    If ($Console64 = Get-ItemProperty -Path HKLM:\SOFTWARE\Wow6432Node\Microsoft\ConfigMgr10\Setup -Name ProductCode -ErrorAction SilentlyContinue
    ) {
       
       
    # 64-bit system
        $ModulePath = (Get-ItemProperty HKLM:\SOFTWARE\Wow6432Node\Microsoft\ConfigMgr10\Setup -Name "UI Installation Directory").'UI Installation Directory'
        $SiteServerName = (Get-ItemProperty HKLM:\SOFTWARE\Wow6432Node\Microsoft\ConfigMgr10\AdminUI\Connection -Name Server).
    Server 
       
    $ProviderLocation = gcim -ComputerName $SiteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"
        $ProviderMachine = $ProviderLocation.
    Machine
       
    $SiteCode = $ProviderLocation.
    SiteCode
       
    Import-Module $ModulePath\bin\ConfigurationManager.psd1
        Set-Location $SiteCode":\"
     
        }


    ElseIf ($Console32 = Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\ConfigMgr10\Setup -Name ProductCode -ErrorAction SilentlyContinue
    ) {
       
       
    # 32-bit system
        $ModulePath = (Get-ItemProperty HKLM:\SOFTWARE\Microsoft\ConfigMgr10\Setup -Name "UI Installation Directory").'UI Installation Directory'
        $SiteServerName = (Get-ItemProperty HKLM:\SOFTWARE\Microsoft\ConfigMgr10\AdminUI\Connection -Name Server).
    Server 
       
    $ProviderLocation = gcim -ComputerName $SiteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"
        $ProviderMachine = $ProviderLocation.
    Machine
       
    $SiteCode = $ProviderLocation.
    SiteCode
       
    Import-Module $ModulePath\bin\ConfigurationManager.psd1
        Set-Location $SiteCode":\"
     

        }


    Else
     { 
       
    $CustomError = [String]"Error: The required registry keys cannot be found. Please ensure the console has been installed on this computer"
     
       
    Throw $CustomError
        }
    }


    $psISE.CurrentPowerShellTab.AddOnsMenu.Submenus.Add("Connect-ConfigMgr",
     
    {
       
    Connect-ConfigMgr
    },"ALT+F1") | out-Null

    Save the file and re-open the ISE. You’ll now have a Connect-ConfigMgr option in the Add-Ons menu. You can either select this option, or just press Alt+F1 from the ISE and your console will connect to your console configured SMS Provider.

    image

    I've also added this script to the TechNet Gallery - https://gallery.technet.microsoft.com/PowerShell-ISE-Add-On-to-4790e37b 

    I hope this significantly speeds up your ConfigMgr work in the PowerShell ISE!

    Matt

  • DPUpgradeThreadLimit Modification

    I’ve recently spent some time with a customer deploying a large amount of Distribution Points in their ConfigMgr 2012 R2 hierarchy. They were finding themselves running into bottlenecks during the deployment, and with the help of the ConfigMgr Product Group, a new Site Control File property modification is now being supported.

    Distribution point installations or upgrades may take longer than expected in System Center 2012 Configuration Manager

    http://support.microsoft.com/kb/3025353 

    The DPUpgradeThreadLimit property by default is set to five. The property should be carefully increased in environments where many Distribution Points are being installed/upgraded in parallel.

    As the property is not visible by default, we need to create and set the new property. This will add the property and set it to the $newValue value across all of your Sites.

     This script is provided as-is and provides no warranties. Please thoroughly test in a lab environment, and see the Configuration Manager SDK for more information.

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    012
    013
    014
    015
    016
    017
    018
    019
    020
    021
    022
    023
    024
    025
    026
    027
    028
    029
    030
    031
    032
    033
    034
    035
    036
    037
    038
    039
    040
    041
    042
    043
    044
    045
    046
    047
    048
    049
    050
    051
    052
    053
    054

    param(
    [string] $siteServerName=".",
    [int] $newValue=10
    )

    $providerLocation = gcim -ComputerName $siteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"
    $providerMachine = $providerLocation.Machine
    $sitecode = $providerLocation.SiteCode
    $providerNamespace = "root\sms\site_" + 
    $sitecode
    $siteFilter
     = "SiteCode='" + $sitecode + "'"

    $distmgrConfig = gcim -ComputerName $providerMachine -Namespace $providerNamespace SMS_SCI_Component | ? {$_.ComponentName -eq "SMS_DISTRIBUTION_MANAGER"}

    ForEach ($distMgrObject in $distmgrConfig
    )  {

       
    $properties = $distMgrObject | select -ExpandProperty Props
        $threadLimitProperty = $properties | ? {$_.PropertyName -eq "DPUpgradeThreadLimit"
    } 
       
    if($threadLimitProperty -eq $null
    )
        {
           
    write-host "Previous setting for DPUpgradeThreadLimit was using default, updating to $newValue"
            $newProperty = New-CimInstance -ComputerName $providerMachine -Namespace $providerNamespace -ClassName SMS_EmbeddedProperty
            $newProperty.PropertyName = "DPUpgradeThreadLimit"
            $newProperty.Value = $newValue

            $newPropertyList =
     @()
           
    $properties | % { $newPropertyList += $_
    }
           
    $newPropertyList += $newProperty
       
           
    $distMgrObject.Props = $newPropertyList
            scim $distMgrObject
        }
       
    else
        {
           
    write-host "Previous setting for $($DistMgrObject.SiteCode) DPUpgradeThreadLimit was $($threadLimitProperty.Value), updating to $newValue"
            $newProperty.PropertyName = "DPUpgradeThreadLimit"
            $newProperty.Value = $newValue

            $newPropertyList =
     @()
           
    $properties | %
     { 
               
    if($_.PropertyName -eq "DPUpgradeThreadLimit"
    )
                {
                   
    $_.Value = $newValue
                    $newPropertyList += $_
                }
               
    else
                {
                   
    $newPropertyList += $_
                } 
            } 
       
           
    $distMgrObject.Props = $newPropertyList
            scim $distMgrObject }
    }
     

  • Script to remind Office 365 users to enrol their device to InTune

    When I have a little downtime (which isn’t often!), I like to sit around and think of cool things I can automate using PowerShell. I have a .txt file that I put all these ideas into and every now and then have a crack at solving one.

    Just recently I was playing around with Office 365 and Windows InTune and this idea struck me.

    With the licensing model of Office 365 being user based, people are syncing their mail to more and more devices. They’ll have Outlook on their work laptop, email syncing on their Windows Phone, and probably syncing on their Apple and/or Android tablet as well. The problem with having so many devices is IT tracking and managing their corporate data. Of course, InTune is the obvious tool to manage these devices.

    Getting your users to enrol their devices into InTune is one of the main challenges. As the registration has to happen from the end users side, I thought I’d write a script to help pester your users into registering their iPads, iPhones, Androids and WPs into your InTune MDM.

    The idea is for this script to be run as a scheduled task. It will connect to your o365 tenant subscription and discover all those users who have synced their device with o365 since the last scheduled task ran. It will then send that user an email reminding them to enrol their device to InTune.

    The email to your users can obviously be customized, but here’s a look at what I’ve given you by default

    image

    I’ve also added a testing mode switch, so you don’t spam your o365 users while doing your dev and test.

    Here’s the script.

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    012
    013
    014
    015
    016
    017
    018
    019
    020
    021
    022
    023
    024
    025
    026
    027
    028
    029
    030
    031
    032
    033
    034
    035
    036
    037
    038
    039
    040
    041
    042
    043
    044
    045
    046
    047
    048
    049
    050
    051
    052
    053
    054
    055
    056
    057
    058
    059
    060
    061
    062
    063
    064
    065
    066
    067
    068
    069
    070
    071
    072
    073
    074
    075
    076
    077
    078
    079
    080
    081
    082
    083
    084
    085
    086
    087
    088
    089
    090
    091
    092
    093
    094
    095
    096
    097
    098
    099
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160


    $O365Username = "your@username.onmicrosoft.com" #Add your o365 admin username here
    $SendEmail = $true #Change this to $false during testing. Output will be returned to the console
    $DeviceRegistrationTimeFrame = -1000000 #Set this to the schedule of your scheduled task
    $InServiceMode = $true 
    #Configure this to $true when running as a scheduled task. This stops the PSSession from unloading everytime it's run

    # Ensure o365 session

    $SessionState = Get-PSSession 
    ForEach ($Session in $SessionState) {If ($Session.ConfigurationName -ne "Microsoft.Exchange") {Connect-O365}}
    If (!$SessionState) {Connect-O365} 

    # Get o365 data
    Get-MobileDevice | Where{$_.WhenCreated -gt (Get-Date).AddHours($DeviceRegistrationTimeFrame)}  | ForEach-Object {

    $User = Get-User -Identity $_.UserDisplayName 
    $AccountDisplayName = $User.DisplayName
    $AccountFirstName = $User.FirstName
    $AccountEmail = $User.WindowsEmailAddress
    $DeviceId = $_.DeviceId
    $DeviceOS = $_.DeviceOS
    $UserDisplayName = $_.UserDisplayName
    $ClientType = $_.ClientType
    $IsCompliant = $_.IsCompliant
    $IsDisabled = $_.IsDisabled
    $Name = $_.Name
    $WhenChanged = $_.WhenChanged
    $WhenCreated = $_.WhenCreated
    $Id = $_.Id
    $IsValid = $_.IsValid

    # Email authorization

    If ($IsDisabled -eq $true) {$SendEmail = $false}
    If ($IsValid -eq $false) {$SendEmail = $false} 

    # Mail info

    $SMTPServer = "smtp.office365.com"
    $SMTPPort = 587
    $SMTPCredential = $UserCredential 
    $EmailRecipient = 
    $AccountEmail
    $EmailSender
     = 
    $O365Username
    $EmailSubject
     = "$AccountFirstName, don't forget to enroll your device to InTune!"
    $Body = `
    "<html>
    <head>
    <title>Enroll Your Device Today!</title>
    <style>
    body {
    font-family: Verdana;
    }
    #HeadingTitle {
    text-align: center;
    font-size: large;
    margin-top: 10px;
    color: blue;
    }
    #HeadingBox {
    width: 60%;
    height: 70px;
    background-color: yellow;
    position: absolute;
    top: 10px;
    left: 20%;
    right: 20%;
    vertical-align: middle;
    background-color: white;
    }
    #BodyText {
    width: 60%;
    height: 60%;
    position: absolute;
    top: 100px;
    left: 15%;
    right: 20%;
    vertical-align: middle;
    text-align: center;
    }
     
    table.center {
        margin-left: auto;
        margin-right: auto;
    font-size: x-small;
    position: relative;
    top: 30px;
    color: gray;
    }

    </style>
    <body>
    <div id=""BodyText"">
    <!-- Intune logo. Please add your company logo too. -->
    <img src=""https://secure.aadcdn.microsoftonline-p.com/aadbranding/1.0.1/aadlogin/Intune/logo.png""></img><p>
    <!-- First line ""Hello Name,"" -->
    Hello $AccountFirstName, <p>
    <!-- Second line ""Thank you for syncing your device with Office 365!"" -->
    Thank you for syncing your device with Office 365! <p>
    <!-- Third line ""To ensure your device is fully managed and supported by the internal IT team, please ensure you enroll your device to InTune via the URL below"" -->
    To ensure your device is fully managed and supported by the internal IT team, please now enrol your device into InTune via the link below <p>
    <!-- Fourth line: link to the manage portal -->
    <a href=""http://manage.microsoft.com"">Manage My Device!</a><p>
    <!-- Fifth line ""Thanks,"" -->
    Thanks,<p>
    <!-- Sixth line ""Your IT Team"". Please add your IT department -->
    <b>Your IT Team</b>
    <!-- Device Details -->
    <table class=""center"">
    <tr>
      <td><b>Username</b></td>
      <td>$UserDisplayName </td>
    </tr>
    <tr>
      <td><b>Enrolled</b></td>
      <td>$WhenCreated </td>
    </tr>
    <tr>
      <td><b>Device OS</b></td>
      <td>$DeviceOS </td>
    </tr>
    <tr>
      <td><b>Device ID</b></td>
      <td>$DeviceID </td>
    </tr>
    </table>
    </div>
    </body>
    </html>"


    # Send Email
    If ($SendEmail -eq $true) {
    Send-MailMessage -To $EmailRecipient -From $EmailSender -Subject $EmailSubject -UseSsl -Port $SMTPPort -SmtpServer $SMTPServer -Credential $SMTPCredential   `
    -BodyAsHtml -Body $Body }
    Else {
    Write-Host "----- Output to console for testing -----"
    Write-Host "----- To: $EmailRecipient -----"
    Write-Host "----- From: $EmailSender -----"
    Write-Host "----- Subject: $EmailSubject -----"
    Write-Host "----- Body: Not added to testing -----"
    }

    }


    # Close Session if not in service mode
    If ($InServiceMode = $false) {
    Get-PSSession | ForEach-Object {If ($_.ConfigurationName -eq "Microsoft.Exchange") {Disconnect-o365 $_.
    ID}} 
    }


    Function Connect-O365 {

    $UserCredential = Get-Credential -UserName $O365UserName  -Message "Enter o365 password"
    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
    Import-PSSession $Session
     

    } 


    Function Disconnect-o365 ($SessionID) {

    Remove-PSSession $SessionID

    }

    Matt Shadbolt

  • PowerShell Script to check active package distributions

     

    Hi All,

    I had a need at a customer to write a script that would identify any active package distributions at a primary site via WMI. Although DPJobMgr will also give you more information and control this script returns a quicker result and in the case I was dealing with when you have a large number of active package distributions this can come in handy. Hopefully you'll find it useful.

    The script is based on the SMS_DistributionJob Server WMI Class

     

    (UPDATE. Matt just provided me with the following code that will give you your Primary site code automatically from WMI. thanks Matty.

    ##################################################

    $providerLocation = gcim -ComputerName $siteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"

    $sitecode = $providerLocation.SiteCode

    $providerNamespace = "root\sms\site_" + $sitecode

    ###################################################

    Updated script below

    )

    ####################################################################################################################################

    ##Check the content distribution queue on a primary

    $providerLocation = gcim -ComputerName $siteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"
    $sitecode = $providerLocation.SiteCode
    $providerNamespace = "root\sms\site_" + $sitecode

    $count = (Get-WmiObject -Namespace $providerNamespace -Class SMS_DistributionJob).count

    $Activethreadcount = (Get-WmiObject -Namespace "root\SMS\Site_$($SiteCode)" -Class SMS_DistributionJob | Where {$_.Starttime -ne $null}).Count

    $Activethreads = Get-WmiObject -Namespace "root\SMS\Site_$($SiteCode)" -Class SMS_DistributionJob | Where {$_.Starttime -ne $null} | Format-List -Property Starttime, RemainingSize

    Write-Output "Total Current Active Distributions $($count)"

    Write-Output "Total Active Threads Count $($Activethreadcount)"

    Write-Output "Current Threads" $Activethreads

    ####################################################################################################################################

    Feel free to post any updates or even scripts that you've written in the comments below.

    If you want to look at other classes that could provide you with more information just check out the following MSDN reference

    http://msdn.microsoft.com/en-us/library/hh948405.aspx

  • 20 Years Of SMS/Configuration Manager

    On the 7th of November 1994, a little product called Systems Management Server (SMS) 1.0 was released. Since that date, there have been four major revisions (SMS 2.0, SMS 2003, ConfigMgr 2007 and ConfigMgr 2012), three Service Packs (ConfigMgr 2007 SP1 & SP2, ConfigMgr 2012 SP1), three Rx releases (ConfigMgr 2007 R2 & R3, ConfigMgr 2012 R2) and countless Release Candidates/Betas, Cumulative Updates (CU’s) and Hotfixes!

    I thought it would be really cool to check out the Wayback Machine for the TechNet page for the day that SMS 1.0 was released, but back then TechNet.com wasn’t even around! (how did we ever find our supportability numbers!)

    The first mention of SMS on the Wayback Machine TechNet is in mid 2000 and talked about deploying SMS 2.0, administering Inventory and Software Metering, as well as the standard Server Sizing advice we all so heavily rely on. (in their Contoso sizing example, the Central Site with 14k clients required a server with a whopping 300-MHz processor and 256 MB of RAM!)

    image

    http://web.archive.org/web/20000817202621/http://www.microsoft.com/technet/sms/ 

    (I love that the comments and suggestions hyper-link is a mailto:technet@microsoft.com)

    I was fortunate enough to not have really dealt with SMS, starting my Systems Management journey with Configuration Manager 2007 but some of my colleagues remember those days well.


    Sebastian Baboolal, Senior PFE at Microsoft

    I started with SMS 2.0. SP5 back around 2004.

    I was working for Microsoft support back then. We had one week of training and we were put on the phones.Classic trial by fire. My first call was a critsit for a customer. They had a large environment at the time > 100K clients being managed. They had a top-level SMS site. Then sites under that with lots of other primary sites under those. One of the 2nd tier primaries went belly up. Had to do a DR on that site. We didn’t cover DR at all in the training (just my luck). Back then you had to go thru like 20 pages of stuff to get the site back up. I was on that call for 14 hrs. Did not leave my desk. We got it fixed but then I was thinking what in the world did I get myself into. Smile
    Glad we’ve moved on from CAPs and smsclitoken accounts but did like die_evil_bug_die and dial_me_in_baby


    George Smpyrakis, Senior PFE at Microsoft

    I started with SMS 1.2 back in 1997. I had just started in IT straight out of Uni and helped setup these Site Servers that seemed to take an entire day to complete. I took these boxes out to a couple of remote sites and got them up and running then started the long and arduous procedure of attempting to install the client on the workstations. At the time we used it as a  Remote control tool for the workstations and In the end it only lasted a couple of months before we removed it and that was a monumental effort in itself as the client seemed to never go away. A few years later a lovely virus called Nimda came along and brought the company I was working for to a halt. We literally had to go around the State of Victoria with floppy disks (Look it up for those under 30.) to patch each workstation so we could bring Internet access back. That’s when my Manager came up to me and said I want you to run with SMS so we never have to do that again. So I then Implemented and starting using SMS 2.0 and have never looked back…


    Anthony Watherston, PFE at Microsoft

    I started with SCCM 2007 implementing it because I had nothing better to do and looking to expand my horizons – some of my favourite memories.

    • Reading through log files in Notepad until my eyes hurt – then discovering trace32
    • The satisfaction of being able to remotely rebuild machines – we used to have people ship the box to us so it could be rebuilt
    • Finally patching an enterprise – then fighting with people because they wouldn’t reboot their machines when patches were installed
    • Releasing a hotfix to 180 secondary servers then watching as all the high impact tickets rolled in because all the site systems were reinstalling.
    • Learning patience when installing new sites – sometimes things just take time to appear in the console
    • Working all day on an issue – then doing a site reset and fixing it instantly

    Through all this though it is one of the most complex systems management products and only limited by your imagination as to what you can do!


    Russell Stevens, Senior PFE at Microsoft

    I started with SMS (slow moving software) version 2.0 RTM in a distributed environment at a UK government department that may have had something to with mail in 2000…

    Highlights include:

    • SMSServer and SMSClient connection accounts for hundreds of Primary and Secondary sites.
    • Software Metering ‘mark one’
    • Switching from NT 4.0 domains to Active Directory domains (see point one).
    • Restoring SMS 2.0 without a wizard, hours and hours and then monitoring for weeks and weeks.
    • Preinst.exe became a useful companion from 2.0 -> 2003 -> 2007 –> 2012
    • Seeing the feature packs become part of the Configuration Manager OSD\BDD, Software Updates (remember ITMU……..)
    • Gigantic DDR backlogs.

    It has been a great ride with some ups and downs, and has delivered some outstanding results over the 20 years, loved it.


    So here’s to ConfigMgr! May our next 20 years be full of smooth CU upgrades, clear of inbox backlogs and void of all accidental deployments!

    Matt Shadbolt

  • Managing APP-V Deployments in ConfigMgr 2012

    Many customers are still configuring collection structures similar to 2007 and using collections to control the validity of who should receive which applications.

    Where possible we should be changing how we now manage application deployments and move the validity processing of the application back to the client by using our Global Conditions (state based) to manage Requirement Rules. This works well for many Off The Shelf (OTS) applications that do not have specific procurement constraints as we can safely deploy this category of applications to ALL USERS and if needed implement an Application Approval workflow. Where I am increasingly seeing customers still reverting back to specific targeted of applications, normally based of an AD Security Group, is for APP-V application deployments.

    I continue to see a large uptake of APP-V in many customer sites as we move towards a user-centric mobile environment, which is great, however I am seeing a lot of customers experiencing poor publishing times of virtual applications which is often a result of poor administrative processes.

    In SCCM 2007 we had the option to instruct the virtual application advertisement to auto remove the virtual application when the advertisement was no longer available to a client. Unfortunately this option is no longer available in 2012 and as a result many customers have gone searching for a solution by looking to the ConfigMgr Community forums. Unfortunately a lot of members of the community are simply recommending to use the general deployment rule that an INSTALL deployment takes precedence over an UNINSTALL deployment.  As a result many of the community forums have been instructing customers to simply create an UNINSTALL deployment for each virtual application and target this to the ALL USERS or ALL SYSTEMS collections. Please DO NOT DO THIS as you will continue to experience slow publishing times for APP-V applications.

    If you are already doing this approach, I strongly recommend you read this blog to understand why this is a BAD idea and be VERY CAUTIOUS in your approach to undo this setup. DO NOT do a BIG BANG approach and remove all of the current UNINSTALL deployments in one hit and create the new recommended workflow as this will cause a huge amount of deployment policy objects potentially causing significant issues in your environment. It would be very advisable that you slowly stage the changes in your environment over a few days to prevent a mass number of policy changes in one hit.

    When to use explicit collections for Tier 2 applications?

    Only when you have specific LOB applications that require a REQUIRED Deployment.

    • Valid Reason: APP-V Deployments where an automatic unpublished workflow is required

    AGAIN DO NOT Target APP-V Uninstall deployments to the ALL USERS / ALL SYSTEMS collection as mentioned in many other forums. This will only delay your application publishing times and add unnecessary load on your ConfigMgr environment.

    Understanding WHY this is BAD practice

    When a client polls for new policy changes, a SPROC is run by the Management Point consuming SQL resources.

    The more records in ResPolicyMap and DepPolicyAssignment, the more CPU time required to process the “GET” SPROC like

    MP_GetMachinePolicyAssignments – Machine Targeted Deployments

    MP_GetUserAndUserGroupPolicyAssignments – User Targeted Deployments

    ResPolicyMap maps the resource ID and PADBID, (unique identifier for the policy). You can Query the count of ResPolicyMap objects to determine the number of policies being targeted to each user / system that must be processed.

    DepPolicyAssignment links a policy object with its dependency polices and are provided to both users &/or machines when a policy request is initiated.

    Examples:

    • Application Requirement Rules defined
    • Multiple Deployment Types per application

    How you should mange APP-V Deployments in your environment

    • Minimise the number of Required Deployments to the ALL USERS / ALL SYSTEMS Collections.
    • Prevent making any large policy changes that target the ALL USERS / ALL SYSTEMS collections, or any large number of objects in one hit.
    • Create an explicit UNINSTALL Collection for each REQUIRED Install Deployment.
    • Base the Collection membership on the compliance state of the application = true and exclude the INSTALL collection.

    Below are examples of the Collection Queries you can use to manage an auto un-publish workflow for App-V deployments based off an AD Security Group.

    USER Centric Deployments.

    1. Create an AD Security group for the application you are deploying.

    2. Create an INSTALL Collection for each Virtual Application with a dynamic query linked to the AD Security Group. Target the INSTALL Deployment for each APP-V Application to this Collection.

    2. Create a specific UNINSTALL Collection for each Virtual Application with a dynamic query using the syntax below. Also add an explicit EXCLUDE Collection membership rule that excludes the INSTALL Collection for that application. Ensure the application name matches that listed in the ConfigMgr database.

    select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain
    from SMS_R_User inner join SMS_G_System_AppClientState on SMS_R_USER.UniqueUserName = SMS_G_System_AppClientState.UserName
    where SMS_G_System_AppClientState.AppName = "APPLICATIONNAME"
    and G_System_AppClientState.ComplianceState = 1

    Example

    image

    image

    image

    image

    Create and Target the UNINSTALL deployment policy to the UNINSTALL Collection.

    The result will be…. When a User is added to the AD Security Group the virtual application will be made available to the end user and install silently. When the user is removed from the AD Security group that has previously successfully published the APP-V application, they will be added to the UNINSTALL collection resulting in the virtual application being automatically removed from the client only then. This approach will minimise the ongoing policy objects that every user in the organisation will have to process.

    Disclaimer: The queries and examples provided in this post are offered “AS IS” and should be used at your own discretion. Please ensure extensive testing be done before implementing this solution into any production environment. While this solution has been tested and confirmed, the ConfigMgrDogs team takes no responsibility for any unexpected results this may have in your ConfigMgr 2012 environment.…