Installing Microsoft Hyper-V Server 2016 on Intel NUC Skull Canyon

I recently acquired an Intel NUC (Next Unit Computing) Skull Canyon for using as portable demo and presentation lab. I will mostly run Windows 10 demo VMs and some Windows Server 2016/System Center 2016 VMs on this powerful Mini PC. I decided that I wanted to run Microsoft Hyper-V Server 2016 as the Host for my VMs, and this blog post will detail how I got it up and running.

Setting up the hardware

In addition to the Intel NUC Skull Canyon, I needed to add Hard disk and Memory. The hardware configuration I choose to start with with was:


After adding the Hard disk and Memory, and connecting the NUC to my Home Network via Cable and a HDMI monitor, I was ready to boot it up for the first time. The monitor displayed that the NUC wasn’t able to find a bootable volume, which is expected. That will come next:

Setup Hyper-V Server 2016

I needed to add a bootable volume for which I could install Hyper-V Server 2016, and prepared an USB stick for which I would boot up the installation media for Hyper-V Server 2016. The following blog post from Thomas Maurer had the information I needed to create the selected bootable USB media:

When booting the NUC, Hyper-V Server 2016 setup started:


After some installation configuration choices, the setup was quickly finished.


After installation and changing the Administrator account password before first time logon, the Server Core configuration was ready for to start configure the Hyper-V Server Host.

I first did these changes:

  • Renamed the Computer Name, in this case I renamed the Computer to ELVEN-NUC-HV1
  • Renamed the Workgroup name (optional)
  • Enabled Remote Desktop (All clients, less secure). This setting can be reversed after I have configured all the Remote Management scenarios I need to.
  • Under Configure Remote Management, I also Enabled the Server to Response to Ping, that could be useful when setting up the Server.
  • I also downloaded and installed any pending updates.


My next step was to configure the Hyper-V Host Server for Remote Management via Hyper-V Manager.

Configure the Hyper-V Host for Remote Management

I want to use my Windows 10 machine and Hyper-V Manager to remote manage this Hyper-V Host, as described in this link:

As this will be my home/portable lab, the Hyper-V Server will not be in a domain, so I need to use the instructions at the end of the above article for Manage a Hyper-V host outside your domain (or with no domain).

This is the steps I went through to set that up:

Configure FQDN for the Hyper-V Host

I want to set the FQDN for the Hyper-V Host so that:

Computername = ELVEN-NUC-HV1
Desired Primary DNS Suffix =

In Command Prompt, I first add the FQDN of the computer with the Netdom command:

netdom computername %computername% /

Second, I add the FQDN of the computer to primary:

netdom computername %computername% /

Add the FQDN and IP address to the Hosts file

To be able to access the Hyper-V Server from my Windows 10 client, I add the IP address (I have created a DHCP reservation for it on my Router) and the FQDN in my Hosts file in C:\Windows\System32\Drivers\Etc directory.


Configure Remoting on the Hyper-V Server

On the Hyper-V host to be managed, start PowerShell.exe, and run the following as an administrator:


Enable-PSRemoting will create the necessary firewall rules for private network zones.

To make sure that the connection are in the private network zone, I check with the command:


In my case, as this server is in a workgroup, I must specifically change the network zone from public to private:

Set-NetConnectionProfile -InterfaceIndex 4 -NetworkCategory Private

When checking after that, the connection is now Private:


After that I run the following command:

Enable-WSManCredSSP -Role server

Configure the Client

On my Windows 10 client machine, I run the following commands in a PowerShell (Run As Administrator) session:

# Start the WinRM Service
Start-Service WinRm

# Add the Hyper-V Server as Trusted Host
Set-Item WSMan:\localhost\Client\TrustedHosts -Value “”

# Add the Hyper-V Server to the list of servers to delegate credentials to
Enable-WSManCredSSP -Role client -DelegateComputer “”

If you later when adding the Server to Hyper-V Manager, get this error message, you need to follow these instructions on the client via GPedit.msc:

Configure the following group policy: * Computer Configuration | Administrative Templates | System | Credentials Delegation | Allow delegating fresh credentials with NTLM-only server authentication *

Click Enable and add wsman/



Add the Server to Hyper-V Manager

Finally, we should be ready to add the Server to Hyper-V Manager:

  1. Select Connect to Server, specify name and Connect as your Admin user:


  2. And now I can successfully configure the Hyper-V Server:


I can now start adding VMs to the Server, that might be a topic for a later blog post Winking smile


Speaking at UC Day UK 2016

I’m excited to be speaking at UC Day UK at the National Conference Centre, in Birmingham, 24th October 2016. If you are interested in attending or reading more, visit this link

My session will be on Azure Active Directory and how you can perform Premium Management and Protection of Identity and Access with Azure AD, covering solutions like Privileged Identity Management, Identity Protection, Multi-Factor Authentication and Azure AD Connect Health. I will show some nice demos as well, hope to see you there!


In addition to my session I will during the day be interviewed on The Skype Show ( about Azure AD and Identity and Access, some of these sessions will go live on Microsoft Channel 9 if logistics permit, or via Skype for Broadcast Meetings or Skype Meetings, and in anyway be recorded and released on Channel 9, Youtube and The Skype Shows website.


UC Day will cover technologies like Skype for Business, Exchange, Office 365, Azure and Cloud, and with 25 breakout sessions over 5 tracks, together with expo and sponsors, keynote and closing note. I very much look forward to come there!


How to enable Azure MFA for Online PowerShell Modules that don’t support MFA?

In this blog post I will look into how you can accomplish Azure Multi-Factor Authentication for Admins even though the Online PowerShell Module don’t support it. The key to do this is to implement and use Azure AD Privileged Identity Management, which is an Azure AD Premium P2 / EMS E5 feature.

The Problem

Administration of Online Services with PowerShell can be done with different PowerShell modules or for some scenarios setting up a remote session to the Online Service.  But not all scenarios support Azure MFA natively.

A quick overview of the main modules that DO support Azure MFA today:

  • Azure PowerShell. Supports Azure MFA with Add-AzureAccount.
  • Azure Resource Manager PowerShell. Supports Azure MFA with Login-AzureRMAccount.
  • Azure Active Directory PowerShell MSOnline Module. Supports Azure MFA with Connect-MSOLService.
  • The Public Preview of Azure AD v2 PowerShell ( Supports Azure MFA with Connect-AzureAD.
  • Azure Rights Management Service PowerShell. Supports Azure MFA with Connect-AadrmService.
  • SharePoint Online PowerShell. Supports Azure MFA with Connect-SPOService.

All of these above supports Azure MFA as long as you are not passing in a Credential object. There are also more advanced scenarios for programmatic access with Access Token and Certificates that I will not cover here for some of these modules. The main thing is that when you create a Credential object with Get-Credential, and pass that in as a Parameter to the above modules, Azure MFA will not work if the Admin user has been configured to use that. We’ll see some examples later in the blog. Note also that if you have an older version of MSOnline or Aadrm which required the Online Sign-In assistant, these will not work with Azure MFA and you must upgrade to the latest versions.

So what about the modules and scenarios that don’t support Azure MFA. These are mainly Office 365 and Remote PowerShell:

  • Exchange Online Remote PowerShell
  • Skype for Business Online Remote PowerShell
  • Office 365 Security & Compliance Center Remote PowerShell

In these scenarios you must create a Credential object, and pass that in as a parameter when connecting to the service, thus blocking the use of Azure MFA.

A Security Best Practice for Admins

Today I just don’t find it acceptable for Admin accounts for any Online Service like Azure or Office 365, to not use Multi-Factor Authentication or some other protection mechanism, and just depend on username and password!

In addition to that, as an Organization you have to have control of your identities, employees and admins come and go, I have seen many times that Organizations still have Admin accounts for users that have left the company for a long time ago.

Most Organizations have Directory Synchronization from local Active Directory to Azure AD, making it possible to synchronize your local admin accounts. You then have a choice: Should I use synchronized admin accounts for the Admin Roles in Azure/Office 365? Or should I only create Cloud only admin accounts for this purpose?

My security best practice is to use a combination of both, so that:

  • Synchronized On-Premise Admin Accounts for the most important, permanent and sensitive admin accounts, like Global Admins, Security Admins, Azure Subscription Admins and more. These accounts will be set up to require Azure MFA, as these accounts possibly can connect to On-Premise resources.
  • Cloud Only Admins accounts for Role Based Administration, additional temporary Global Admins or other scenarios for intermittent Azure and Office 365 administration. These accounts will not be set up for Azure MFA, but I use Azure AD Privileged Identity Management to require Azure MFA when activating the role. Some of these accounts also includes service accounts for Directory Synchronization, Intune Connector etc.

The Solution

I have found that the best way to protect both type of Admin accounts is to use the Azure AD Privileged Identity Management and Azure MFA in combination so that:

  • In general all of the permanent Admin Accounts with a few exceptions are required to use Azure MFA. These Admin accounts can use all PowerShell modules that support MFA when connecting.
  • Role-based admins (for example Exchange Admins, Skype for Business Admins,..) are set up to be Temporary/Eligible Admins in Azure AD Privileged Identity Management, which require Azure MFA at activation time. After the admin role is activated, he or she can use the PowerShell modules/remote sessions that don’t support Azure MFA natively.

The downside of this solution is that Azure AD Privileged Identity Management require an Azure AD Premium P2 license or Enterprise Mobility E5 license, which will be Generally Available Sept 15th. Azure MFA are free to use for Admin accounts for Online Services.

How to set it up

In the following steps I will show how to set this up and how it will work. For the purpose for this demo I will work with my demo environment with the tenant name I have also configured directory synchronization from my on-premise Active Directory, these users will have a UPN suffix of

In my environment I have a fictional character called Ola Nordmann. Ola is an Exchange Admin in our Hybrid Exchange environment, and needs permissions to administer Exchange Online in Office 365 both via the management portal and via Exchange Online PowerShell.

Ola has these two accounts now in Azure AD:


As per the solution described, I will configure and require Azure MFA for the on-premise admin account, and for the cloud admin account I will use Privileged Identity Management and MFA for role activation.

Configure Multi-Factor Authentication

The easiest way to enable MFA for a user is via the Office 365 Admin portal at In the user list I find and select the admin user I want to enable MFA for:


The Manage multi-factor authentication will take me to the Azure AD multi-factor authentication administration page, where I find and select the admin user:


On the right-hand side I select to Enable for the selected user(s):


After that I confirm that I want to enable MFA for the user:


And get confirmation:


Now I see that the status is Enabled, this means that the user needs to log on and configure the authentication method for MFA first:


Configure Admin Role

Next, I will give Ola Nordmann the Exchange Administrator role, so that he can administer Exchange Online.

Back in the Office Admin portal I see that the user now has no roles:


I select Edit, and choose the Customized administrator and Exchange administrator role, and add the e-mail address of the user:


Next, I add the same Exchange administrator role to the Ola Nordmann (Cloud Admin) user:


So, at this time, both admin users are Exchange administrators, but only the on-premise admin account has been configured for multi-factor authentication.

Log on and activate multi-factor authentication method for admin user

Now I will log on the account to

Since this admin account has been configured for MFA, I must set that up now:


I need to select an authentication method. In this demo I will use the Microsoft Authenticator App:


I select to set up and configure the mobile app:


I open up the Microsoft Authenticator app on my phone, and follow the instructions from above. After that I get confirmation that the mobile app has been configured.


Now I need to select Contact me to test the authentication:


At my phone I get the notification in the App and select verify, and I should be successful. Since I only have set up the mobile app, I also need to add phone number verification in case I lose access to the app. I type my mobile phone number and press next.


And in the last step I get an app password to use on some apps, I will not be needing this now for this demo, and click Done:


Back in the portal login, I will now be prompted to authenticate with my app:


After successfully authenticating I’m logged in to the portal:


And since this user has an Exchange administrator role, I can see limited information in the Office 365 admin portal and launch the link to the Exchange admin portal:


Try to access Exchange Online PowerShell with MFA enabled admin

First, a quick look back at the multi-factor authentication administration page, where the admin user status has now been updated to Enforced. This happens after the users have been enabled for MFA, and after they have successfully configured their authentication methods. Enforced means that they will now be required to do MFA when authenticating against online services:


Let’s try to access Exchange Online PowerShell with this admin user. Instructions for connecting with PowerShell for Office 365 services are detailed here:

I launch a PowerShell window and get a Credential object:


After that I try to create a remote session with that credential:


As expected this will fail, as multi-factor auhtentication is required for the account.

In the next part we will look at the other cloud admin user and configure the workaround using Azure AD Privileged Identity Management.

Configure Azure AD Privileged Identity Management for Exchange administrators

At this next step I log in as a Global Administrator, and if I haven’t already added the Privileged Identity Management solution, I can add it from the Azure Marketplace:


The first Global Administrator that set up Privileged Identity Management will added to the Security Administrator and Privileged Role Administrator Roles. After that we can manage the privileged roles. If you have previously added the solution, you will have to activate your Privileged Role administrator first.


When I select the Exchange Administrator role, I can see both admin accounts for my Ola admin user. These roles are assigned on a permanent basis:


Azure AD Privileged Identity Management will let me assign and change admin roles from permanent to eligible for temporary activation. I will do this for the cloud admin account:


After I click Make eligible, the admin account are removed from permanent role and are now listed as Eligible:


Lets click on the Settings button for the Exchange Administrator role. At settings I can set the activation duration, email notifications, ticketing and fore some roles I can select whether to require multi-factor authentication for activation:


These settings can also be set as default for all roles:


At this point my cloud admin has been removed as a permanent Exchange Administrator, and will require activation before he will be temporarily activated as an Exchange Administrator for one hour duration.

Log on as admin user without activation

When I log in to the Office 365 portal with the, I will see that this user is just a normal user with no admin links, This is expected as the user hasn’t activated the Exchange Administrator role.


Activate the Exchange Administrator Role

Next I go to the Azure portal at still logged on as First I need to add the Privileged Identity Management solution:


After adding the solution, I can request activation for the roles I’m eligible for, in this case Exchange Administrator:


When requesting activation I need to verify my identity first:


If my account hasn’t already been set up for multi-factor authentication, it will be guided to do that now:


After configuring and verifying multi-factor authentication, I can now activate my Exchange Administrator role and provide a reason:


After successful activation I can verify the duration I will be activated for:


Log on to the Office 365 Portal and Exchange Admin Center after activation

After activation, I should log off and back on with my activated admin role account, and this time I will see the Exchange Admin portal:


Log on to Exchange Online PowerShell after activation

And finally, I can start an Exchange Online PowerShell Session with my activated account. First I get my credential:


Then I can create the remote Exchange Online session and import it to PowerShell:


And finally just try out some Exchange Online administration successfully:



At the end of this long blog post, we can summarize that we have accomplished the solution of adding Azure Multi-Factor Authentication for scenarios where the PowerShell Module or Remoting Session does not natively support it. This is made possible by using Azure AD Privileged Identity Management, and by making some role administrators eligible and require MFA when activating. This way they have verified their identity before they connect with the Credential object.

This is just one scenario where both Azure AD MFA and Privileged Identity Management can be used together for increased security and reduce the attack surface of having vulnerable permanent administrator accounts and roles.

I hope this blog post have been informative and helpful, please reach out or comment if you want to know more or have any questions.


Experts and Community unite at last ever #SCU_Europe 2016! #ExpertsLive next

This years SCU Europe 2016, for the first time outside Switzerland in the 4th year running, was held in Berlin at the BCC (Berlin Congress Center) close to the Alexander Platz in the eastern parts of “Berlin Mitte”.



The intro video introducing the Experts:

Let’s begin with the end: at the closing note SCUE general Marcel Zehner announced and with a little bit of emotion that this was the last ever SCU Europe to be held.. You and your organization should be proud of what you have achieved, Marcel, it is one of the best community conferences around, and I have been fortunate to be able to visit all 4 starting with Bern in 2013, Basel in 2014 and 2015, and now Berlin in 2016. It’s only cities with B’s is it? In fact, you never know what twists and turns your career takes, but looking back I’m not sure I would be where I am now in turn of being presenter, MVP and community influencer myself if I had not travelled alone to Bern 4 years ago, that’s where I really started working with and for the Community (with a capitol C)!

Luckily SCU Europe will continue as Experts Live Europe next year! Same place at BCC, same organization and format, and the same dates only next year it will be: 23rd – 25th of August 2017. A new web page was launched,, and Twitter (@ExpertsLiveEU) and Facebook have been changed to reflect that. The hash tag #SCU_Europe will eventually be inactive and you should now use #ExpertsLive.


I think this is a very good decision, there has already been discussion on that the name “System Center Universe” is not really reflecting the content and focus of the conference, now embracing the Cloud, with content areas for Management, Productivity, Security, DevOps, Automation, Data Platform and more. ExpertsLive, originally a 1-day community conference in Netherland running each year back from 2009 and with up to 1200 participants, will now be a network of conferences, ranging from region based (ExpertsLive Europe, but also SCU APAC and SCU Australia will be ExpertsLive APAC and Australia next year), and local, country based ExpertsLive like the one in Netherlands, but more will come.


The closing note video announcing Experts Live Europe:

This year at SCU Europe I was one of the Experts and presented two sessions on “Premium Identity Management and Protection with Azure AD” and “Deep Dive: Publishing Applications with Azure AD”. I also took part in a “Ask-the-Experts” area together with Cameron Fuller and Kevin Greene where we took questions on the topic System Center 2016. I participated on a discussion panel on Friday morning with Markus Wilhelm from Microsoft Germany on the subject Defense Strategies and Security, and of course we had the Meet and greet with the Experts at the Networking party. It was a really great experience speaking at this conference, thanks for having me!





The content of the conference this year was great, and for the first time there was 5 tracks, with over 70 sessions presented! All presentations and session recordings will be at Channel 9 in a few weeks time, so make sure you look at anything you missed or want to see again if you where there, or if you weren’t at the conference this year you can look at your sessions of interest.

I was travelling with a group this year, both from my company and some of our customers, in total we were 7 in the group, and also had 3 cancellations the last week before the conference from some customers that could not make it after all. Moving the conference to Berlin is a big part of why it now was easier to attract more Nordic attendance I think. We stayed at the Park Inn by Radisson right by the Alexander Platz and BCC, so it was really central and nice.





In good tradition there are a lot of parties and social networking going on. On the first night there are the Sponsors and Speakers Party, which was held in Mio right by the TV Tower by Alexander Platz, on Thursday we had the attendee Networking Party at the conference center. Later that night our group and some more partners/customers of Squared Up went on to another party at Cosmic Kaspar. It was really hot, so basically the party was at the pavement! On the last day we had the Closing Drinks, sponsored by Cireson and itnetX at Club Carambar, also close to the Alexander Platz. In addition, there are a lot of unofficial gatherings going on, lots of laughs and new and old friends have a good time.







See you next year at Experts Live Europe in Berlin 23-25th August, 2017!


Publish the itnetX ITSM Portal with Azure AD App Proxy and with Conditional Access

Last week at SCU Europe 2016 in Berlin, I presented a session on Application Publishing with Azure AD. In one of my demos I showed how to use Azure AD Application Proxy to publish an internal web application like the itnetX ITSM Portal. The session was recorded and will be available later at itnetX’s Vimeo channel and on Channel 9.

In this blog post I will detail the steps for publishing the portal in Azure AD, and also how to configure Conditional Access for Users and Devices. Device compliance and/or Domain join conditional access recently went into preview for Azure AD Applications, so this will be a good opportunity to show how this can be configured and how the user experience is.


itnetX has recently released a new HTML based ITSM Portal for Service Manager, and later there will be an analyst portal as well.

This should be another good scenario for using the Azure AD Application Proxy, as the ITSM Portal Web Site needs to be installed either on the SCSM Management Server or on a Server that can connect to the Management Server internally.

In this blog article I will describe how to publish the new ITSM Portal Web Site. This will give me some interesting possibilities for either pass-through or pre-authentication and controlling user and device access.

There are two authentication scenarios for publishing the ITMS Portal Web Site with Azure AD App Proxy:

  1. Publish without pre-authentication (pass through). This scenario is best used when ITSM Portal is running Forms Authentication, so that the user can choose which identity they want to log in with.
  2. Publish with pre-authentication. This scenario will use Azure AD authentication, and is best used when ITSM Portal Web Site is running Windows Authentication so that we can have single sign-on with the Azure AD identity. Windows Authentication is also default mode for ITSM Portal installations.

I will go through both authentication scenarios here.

I went through these steps:

Configure the itnetX ITSM Portal Web Site

First I make sure that the portal is available and working internally. I have installed it on my SCSM Management Server, in my case with the URL http://azscsmms2:82.

In addition to that, I have configured the ITSM Portal to use Forms Authentication, so when I access the URL I see this:


Create the Application in Azure AD

In this next step, I will create the Proxy Application in Azure AD where the ITSM Portal will be published. To be able to create Proxy Applications I will need to have either an Enterprise Mobility Suite license plan, or an Azure AD Basic/Premium license plan. App Proxy require at least Azure AD Basic for end-users accessing applications, and if using Conditional Access you will need a Azure AD Premium license. From the Azure Management Portal and Active Directory, under Applications, I add a new Application and select to “Publish an application that will be accessible from outside your network”:

I will then give a name for my application, specify the internal URL and pre-authentication method. I name my application “itnetX ITSM Portal”, use http://azscsmms2:82/ as internal URL and choose Passthrough as Pre-Authentication method.

After the Proxy Application is added, there are some additional configurations to be done. If I have not already, Application Proxy for the directory have to be enabled. I have created other Proxy Applications before this, so I have already done that.

After I have uploaded my own custom logo for the application, I see this status on my quickstart blade for the application:


I also need to download the Application Proxy connector, install and register this on a Server that is member of my own Active Directory. The Server that I choose can be either on an On-Premise network, or in an Azure Network. As long as the Server running the Proxy connector can reach the internal URL, I can choose which Server that best fits my needs.

When choosing pass through as authentication method, all users can directly access the Forms Based logon page as long as they know the external URL. Assigning accounts, either users or groups, will only decide which users that will see the application in the Access Panel or My Apps.


I now need to make additional configurations to the application, and go to the Configure menu. From here I can configure the name, external URL, pre-authentication method and internal URL, if I need to change something.

I choose to change the External URL so that I use my custom domain, and note the warning about creating a CNAME record in external DNS. After that I hit Save so that I can configure the Certificate.


After that I upload my certificate for that URL, and I can verify the configuration for the external and internal URL:image

When using passthrough I don’t need to configure any internal authentication method.

I have to select a connector group, where my installed Azure AD App Proxy Connectors are installed, and choose to have the default setting for URL translation. Internal authentication is not needed when using Pass Through authentication:


If I want, I can allow Self-Service Access to the published application. I have configured this here, so that users can request access to the application from the Access Panel ( This will automatically create an Azure AD Group for me, which I either can let users join automatically or via selected approvers:


After I have configured this, I am finished at this step, and can test the application using pass through.

Testing the application using pass through

When using Pass through I can go directly to the external URL, which in my case is And as expected, I can reach the internal Forms Based login page:


For the users and groups I have assigned access to, they will also see the itnetX ITSM Portal application in the Access Panel ( or in My Apps, this application is linked to the external URL:


This is how the Access Panel looks in the coming new look:


Now I’m ready to do the next step which is change Pre-Authentication and use Azure AD Authentication and Single Sign-On.

Change Application to use Azure AD Authentication as Preauthentication

First I will reconfigure the Azure AD App Proxy Application, by changing the Preauthentication method to Azure Active Directory.

Next I need to configure to use Internal Authentication Method “Windows Integrated Authentication”. I also need to configure the Service Principal Name (SPN). Here I specify HTTP/portalserverfqdn, in my example this is HTTP/azscsmms2.elven.local.


PS! A new preview feature is available, to choose which login identity to delegate. I will continue using the default value of User principal name.

Since I now will use pre-authentication, it will be important to remember to assign individual users or groups to the Application. This enables me to control which users who will see the application under their My Apps and who will be able access the application’s external URL directly. If users are not given access they will not be able to be authorized for the application.

Enable Windows Authentication for itnetX ITSM Portal

The itnetX ITSM Portal site is configured for Windows Authentication by the default, but since I reconfigured the site to use Forms Authentication earlier, I just need to reverse that now. See installation and configuration documentation for that.

It is a good idea at this point to verify that Windows Integrated Authentication is working correctly by browsing internally to the ITSM Portal site. Your current logged on user (if permissions are correct) should be logged in automatically.

Configure Kerberos Constrained Delegation for the Proxy Connector Server

I now need to configure so that the Server running the Proxy Connector can impersonate users pre-authenticating with Azure AD and use Windows Integrated Authentication to the Squared Up Server.

I find the Computer Account in Active Directory for the Connector Server, and on the Delegation tab click on “Trust this computer for delegation to specified services only”, and to “Use any authentication protocol”. Then I add the computer name for the web server that the ITSM Portal is installed on and specify the http service as shown below (I already have an existing delegation set up):


This was the last step in my configuration, and I am almost ready to test.

If you, like me, have an environment consisting on both On-Premise and Azure Servers in a Hybrid Datacenter, please allow room for AD replication of these SPN’s and more.

Testing the published application with Azure AD Authentication!

Now I am ready to test the published proxy application with Azure AD Authentication.

When I go to my external URL, Azure AD will check if I already has an authenticated session, or else I will presented with the customized logon page for my Azure AD:


Remember from earlier that I have assigned the application either to a group of all or some users or directly to some pilot users for example.

If I log in with an assigned user, I will be directly logged in to the ITSM Portal:


However, if I try to log in with an Azure AD account that hasn’t been assigned access to the application, I will see this message:


This means that the pre-authentication works and I can control who can access the application via Azure AD.

Conditional Access for Users and Devices

When using Azure AD as preauthentication, I can also configure the application for conditional access for users and devices. Remember this is a Azure AD Premium feature.

From the the configuration settings for the application I can configure Access Rules via MFA and location, and Access Rules for devices which now is in Preview:


If I enable Access Rules for MFA and location I see the following settings, where I can either for all users or for selected groups require multi-factor authentication, or require multi-factor when not at work, or block access completely from outside work. I have define my network location IP ranges for that to take effect.


If I enable Access Rules for devices, I see the following settings. I can select for all users or selected groups that will have device based access rules applied (and any exceptions to that).

I can choose between two device rules:

  • All devices must me compliant
  • Only selected devices must be compliant, other devices will be allowed access

If I select all devices, a sub option for windows devices shows where I need to select between domain joined or marked as compliant, or just marked as compliant or domain joined selectively.


If I select the second option, I can even specify which devices will be checked for compliancy:


So I can with different access rules for both MFA, location and selected devices, in addition to the Azure AD Preauthentication, apply the needed conditional access for my application.

In this case I will select device rules for compliant/domain joined, and for all the different devices. This will mean that for users to access the ITSM Portal, their device must either be MDM enrolled (iOS, Android, Windows Phone) or in the case of Windows devices either be MDM enrolled, Azure AD Joined, Compliant or Domain Joined. Domain joined computers must be connected to Azure AD via the steps described here:

After I’m finished reconfiguring the Azure AD App Proxy Application, I can save and continue and test with my devices.

Testing device based conditional access

Lets see first when I try to access the ITSM Portal via an unknown device:


On the details I see that my device is Unregistered, so I will not be able to access the application.

Now, in the next step I can enroll my Windows 10 Device either through MDM or via Azure AD Join. In this scenario I have added my Windows 10 to Azure AD Join:


If I look at the Access Panel and Profile I will also se my devices:


The administrator can see the Device that the user has registered in Azure Active Directory:


Lets test the published ITSM Portal again:


Now I can see that my device has been registered, but that it is not compliant yet, so I still cannot access the ITSM Portal.

When I log on to the Client Manage Portal (, I can see that my Windows 10 Device not yet are Compliant:


So when I investigate, fix whatever issues this device has and then re-check compliance, I can successfully verify that I should be compliant and good to go:


After that, I’m successfully able to access the ITSM Portal again, this time after my device has been checked for compliance:



In this blog post we have seen have to publish and configure the itnetX ITSM Portal with Azure AD Application Proxy, using both pass-through authentication and Azure AD Preauthentication with Kerberos constrained delegation for single sign-on.

With the additional possibility for conditional access for users and devices, we have seen that we can require either MFA or location requirements, and device compliance for mobile platforms and windows devices.

Hope this has been an informative blog post, thanks for reading!

PS! In addition to access the application via the Access Panel (, I can use the App Launcher menu in Office 365 and add the ITSM Portal to the App chooser:


This will make it easy for my users to launch the application:


Speaking at System Center Universe Europe 2016 – Berlin

I’m really excited that I will have two sessions at this years SCU Europe in Berlin, August 24th – 26th. System Center Universe Europe is a really great community conference that focuses on Cloud, Datacenter and Modern Workplace Management, covering technologies like Microsoft System Center, Microsoft Azure, Office 365 and Microsoft Hyper-V. Read more about SCU Europe here:

I have been visiting all SCU Europe Conferences since the inaugural start in Bern 2013. I met some amazing MVPs, sponsors and community leaders already then, in fact it inspired me even more to share more of my own workings and knowledge by blogging, using social media and eventually speaking at technical  and community conferences myself.  The following two years SCU Europe were held in Basel, both the great conference venue at Swissotel and lest not forget Bar Rouge had its fair share of memorable moments🙂

This years SCU Europe will be held in Berlin from the 24th to the 26th of August. Moving the conference to Berlin is a smart move I think, it will make the conference even more accessible to most European and overseas travelers, and attract the attendance it deserve.

A few months ago I received some great news, I had two sessions accepted for SCU Europe, and received my first Microsoft MVP Award for Enterprise Mobility. I’m really happy to not only go and learn and enjoy the conference sessions and community, but also to contribute myself along with over 40 top, top speakers from all over the world!

My first session will cover “Premium Management and Protection of Identity and Access with Azure AD”:


In the session I will focus on Azure AD Identity Protection, Azure AD Privileged Identity Management for controlling role and admin access, how to monitor it all will Azure AD Connect Health, and how Azure Multi-Factor Authentication works with these solutions. The session will cover the recent announcements regarding Enterprise Mobility + Security.

The second session will be a deep dive on “Publish Applications with Azure AD”:


In this demo-packed session I will go deep into what you need to get started on publishing the different types of applications, and how to configure and troubleshoot user access to these applications. The session will cover Azure AD Single Sign-On and Password Single Sign-On, integrating Azure AD SSO with your internally developed applications, and publishing applications with Azure AD App Proxy that either use pre-authentication or pass through.

Hope to see you at the conference, and if you haven’t registered yet there is still time:


New look coming to Azure Active Directory Access Panel #AzureAD

A quick update on coming changes to the Azure Active Directory Access Panel at

When I log in with my Azure AD work account I see that there is a notification that a new look is coming soon and I can try it out:


The new applications look:


The new groups look, where I can see which groups I own and which I am member of:


For groups I can join or leave, change settings for groups I own and see members.

Looking at my logged in user in the right top corner, I see that I have a notification for pending actions, in this case I have an approval waiting to join a group I own:


Looking more at my profile I can change my associated Azure AD Organizations, or go to my Profile page:


The Profile page has a new look as well, where I can see my information, manage my account with password change or reset setup (depending on Azure AD Premium or EMS license and configurations), and I can view my devices and activity status.


This new look seems to be out there for everyone to try out now, and looks great so far.

And by the way: There is still no support for Edge browser when trying to run a published application that use Password SSO and require the Access Panel Extension: