ConfigMgrDogs

  • Where is The System Center Configuration Manager Cmdlet Library

     

     

     

    Hi all, just a quick post today.  I found it difficult to find the location of the latest cmdlet updates for the Configuration Manager  PowerShell module while doing a general search on the web.

    What we now have is The System Center Configuration Manager Cmdlet Library which checks for library updates on a daily basis and notifies you to download the updated library when searching the web. 

    I’ve found that a lot of customers I visit when automating Configuration Manager do have older Powershell cmdlets and are not taking advantage of the latest Powershell cmdelts available to them, so If you haven't updated lately have a look at the link below

    Here is the link the TechNet reference

    https://technet.microsoft.com/en-us/library/dn958404(v=sc.20).aspx

    and the link to the download

    http://www.microsoft.com/en-us/download/confirmation.aspx?id=46681

    Happy automating

    George

  • So you want to test your NDES/SCEP certificate enrollment?

    SCEP (Simple Certificate Enrollment Protocol) and NDES (Network Device Enrollment Service) are the mechanisms we currently use to deploy certificates to our mobile devices via Intune and Configuration Manager. The tech is very (very) cool, but for the average ConfigMgr admin it’s got quite a steep learning curve.

    Once you (kinda) understand how it all works, you’ll begin to test your configuration. Testing NDES and SCEP is a pain in the neck, as there are so many moving parts. Worst is having to troubleshoot certificate enrollment on the tiny screens of your mobile devices.

    Luckily, we can test & troubleshoot via our Windows workstations.

    In my scenario, I’ve got an NDES server hosted in Azure. I know the NDES server is ‘up’ as browsing the URI works fine (http://ndes.mydomain.com/CertSrv/mscep). I want to test that the NDES certificate template is deployed correctly, and the certificate is valid.

    First, you’ll need to create an .inf file that will hold some request information. It should include the requests Subject name and the RequestType as a minimum. You can also add all the optional attributes you want or need. For example, my NDES template has a minimum key length of 2048, so I needed to add the KeyLength attribute too. (Certreq.exe INI File Structure)

    request.inf

    [NewRequest]
    Subject = “CN=TestNDESCert”
    RequestType = SCEP
    KeyLength = 2048

    Once we have our request .inf, we need to create a certificate request. From a command line with Admin elevation

    certreq –v –config ndes.mydomain.com –username MYDOMAIN\Administrator –p Password –new request.inf scepRequest.req

    Lets break this down.

    certreq –v –config ndes.mydomain.com is my NDES server that’s publically available. The certreq documentation notes that to use https you must specify the URI instead of the FQDN, however in my testing on Windows 10 I could not get https to work. From my tracing I found certreq dropping a “http://” in-front of any URL that I passed into the command-line. SO, if you’re using https, you may have to enable http for this sort of testing.

    -username MYDOMAIN\Administrator –p Password is my test users username and password

    -new request.inf scepRequest.req is the verb calling a new request feeding my request.inf (created above) and an output file scepRequest.req

    You should get something like this back from the command

    image

    If you now check on the CA, you should see a certificate has been issues to this client

    image

    Now that we have our request, we need to submit it to the NDES server to receive our certificate.

    certreq -v -config ndes.sa.mattslabs.com -submit scepRequest.req scepCert.cer

    This is pretty straight forward. Submit the newly created scepRequest.req request file, and receive a certificate scepCert.cer from the NDES server.

    Finally, install the certificate and view it in your Certificates – Current User MMC snap-in

    certreq -accept scepCert.cer

    image

    SNAGHTML182d5ef1

    Happy testing!

    Matt Shadbolt

  • Where the heck are my Android Web Apps?!

     

    When I deploy web apps to Android devices they never show up in the Apps list. Where the heck are they!?

     

    Intune Web Apps are basic URL shortcuts that are delivered to Intune managed devices. They’re great for dropping links on devices to your Intranet, your favourite SaaS web portal or that website that all of your users require day-to-day.

    SNAGHTML3528863

    When you deploy a web app to an iOS device, the web app is displayed on the users home screen just like any iOS application.

    Many people expect the same to be true for Android deployments. This isn’t the case. You’ll find the deployed web app from within the Intune Widget.

    To view the web app, you’ll need to add the Intune Widget to your home screen.

    Press and hold the background of your home screen until it allows you to edit the apps/wallpapers/etc. You’ll see a Widgets option. Press that icon.

    image

    Find the Company Portal widget

    image

    Select and hold the widget. You’ll be prompted to drop the widget onto your preferred home screen

    image

    Let it go in place, and you’ll now see your deployed Web Apps

    image

    Matt Shadbolt

  • Starting NDES Services (Device Registration Service) Fails with “object does not exist”

    I ran into this issue when configuring SCEP/NDES certificate registration for an Intune tenant.

    Following all the best practice configuration steps, left me with an SCEP enrollment page returning Internal Server Error 500 instead of the expected 200.

    image

    I found that the Device Registration Service was not starting correctly. In the event logs I found it attempting to start and then stopping

    image

    The two most helpful event are the EventID 137

    image

    Failed to find the Device Registration Service object at DeviceRegistrationService.

    Additional information
    Error Message: The object does not exist..
    Error Result code: NoSuchObject.

    and EventID 157

    image

    An error occurred.

    Additional information
    Error: Failed to find the Device Registration Service object in the configuration naming context in domain contoso.com.

    It’s essentially saying that the DeviceRegistrationService objects have not been successfully written to AD.

    If I browse the Configuration partition of my Active Directory, I can see there is no Device Registration Configuration

    image

    And if I run the following Get-AdfsDeviceRegistration PowerShell cmdlet, I’ll get a configuration error

    image

    To fix this, run Initialize-ADDeviceRegistration

    image

    You’ll then find the Device Registration Configuration objects in your Active Directory

    image

    Start the Device Registration Service again, and all should start as expected.

    image

    Restart the NDES server just to be sure everything is talking correctly, and test the SCEP URL again. This time we should get a 200 instead of 500

    image

    Matt Shadbolt

  • 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 }
    }