There are some really cool new authentication features in Azure and ADFS. Unfortunately they don't play very nicely with Windows Intune and they can be really difficult to troubleshoot if you don't know what the problem is. There are no log files that can point you in the right direction. It just doesn't work.
I've recently seen two of these issues on customer sites:
When you use Multi-Factor Authentication and enroll a device with Windows Intune, you receive the error “This request couldn’t complete”
Workaround: Turn off Windows Azure Multi-Factor Authentication for the Windows Azure subscription you use with Windows Intune.
(Edit 25th November 2014: Azure Multi-Factor Authentication is now supported by Intune)
Windows Phone 8.1 devices fail to enroll with Windows Intune when device authentication is enabled in ADFS
Workaround: Disable device authentication on the ADFS server by unchecking "Enable device authentication" in Edit Global Authentication Policy
The workarounds aren't too clever. The feature is not supported - turn it off.
Here is another one (although I haven't seen this one in action)
When you enroll a Windows 8.1 device that must authenticate to a proxy server, the enrollment process fails with no visible indication as to the cause of the failure
Workaround: For Windows 8.1 devices that must enroll on a network that requires use of an authenticated proxy server, configure and save the credentials for the proxy server prior to enrollment of the device.
These issues have been documented in the "Release Notes for Windows Intune"
http://technet.microsoft.com/en-us/library/jj662694.aspx
Gerry Hampson Device Management
Wednesday, 3 September 2014
Saturday, 30 August 2014
Alternate Login IDs cannot be used with ConfigMgr 2012 and Windows Intune
Back to ConfigMgr main menu
(Edit 17th May 2015: This issue has been resolved by Microsoft and Alternate Login IDs are now fully supported with the ConfigMgr/Intune hybrid solution. This involved updates to the Intune service. The WiKi article (referenced below) has been edited to reflect this. Thanks for the information Stefan Schörling and Jörgen Nilsson.)
I hope that this blog post helps other Consultants to avoid the trap that I fell into. "Alternate Login IDs" are a really cool new feature of Windows Server 2012 R2 Update. They are described in detail here
DirSync: Using Alternate Login IDs with Azure Active Directory
The process involves:
However, it doesn't work with the Unified Device Management solution of ConfigMgr 2012 and Intune. This is because ConfigMgr handles AD user accounts differently. When a user is first discovered all the AD attributes are committed to the ConfigMgr database. This includes the UPN (eg. gerry.hampson@contoso.local). When I add this user to my "Intune Users" collection this change cannot be synchronised to Intune. The CloudUserSync log tells us that the internal AD UPN is being used to sync to Azure. As the DirSync Direct Mapping is not involved in this process it fails - UserNotFound. Of course it does - gerry.hampson@contoso.local does not exist in Azure.
The article above has warned me that I might have a problem:
"If you are an InTune Hybrid customers using the SCCM Connector there may be additional configuration required. Please contact your Account representative for more information."
I contacted Microsoft CSS for this "additional configuration". They were aware of this shortcoming. There is no supported solution at this time - and no estimated time for a possible solution. The suggested workaround is to run a script on the ConfigMgr database to change the UPN for the user accounts to use the public routable domain. Clearly this is not supported so I don't think it's a great idea.
A recent customer engagement had several phases. Phase 1 was an Office 365 migration. They were very pleased to implement the new features so that UPNs did not have to be changed. Phase 2 was the ConfigMgr/Intune solution - guess what - UPNs now had to be changed. It's a real shame because Alternate Login IDs are a cracking new feature.
(Edit 17th May 2015: This issue has been resolved by Microsoft and Alternate Login IDs are now fully supported with the ConfigMgr/Intune hybrid solution. This involved updates to the Intune service. The WiKi article (referenced below) has been edited to reflect this. Thanks for the information Stefan Schörling and Jörgen Nilsson.)
I hope that this blog post helps other Consultants to avoid the trap that I fell into. "Alternate Login IDs" are a really cool new feature of Windows Server 2012 R2 Update. They are described in detail here
DirSync: Using Alternate Login IDs with Azure Active Directory
The process involves:
- Modifying the DirSync attribute flow for UserPrincipalName for provisioning/sync
- Leveraging the Alternate Login ID feature of AD FS for Single Sign-On authentication
However, it doesn't work with the Unified Device Management solution of ConfigMgr 2012 and Intune. This is because ConfigMgr handles AD user accounts differently. When a user is first discovered all the AD attributes are committed to the ConfigMgr database. This includes the UPN (eg. gerry.hampson@contoso.local). When I add this user to my "Intune Users" collection this change cannot be synchronised to Intune. The CloudUserSync log tells us that the internal AD UPN is being used to sync to Azure. As the DirSync Direct Mapping is not involved in this process it fails - UserNotFound. Of course it does - gerry.hampson@contoso.local does not exist in Azure.
The article above has warned me that I might have a problem:
"If you are an InTune Hybrid customers using the SCCM Connector there may be additional configuration required. Please contact your Account representative for more information."
I contacted Microsoft CSS for this "additional configuration". They were aware of this shortcoming. There is no supported solution at this time - and no estimated time for a possible solution. The suggested workaround is to run a script on the ConfigMgr database to change the UPN for the user accounts to use the public routable domain. Clearly this is not supported so I don't think it's a great idea.
A recent customer engagement had several phases. Phase 1 was an Office 365 migration. They were very pleased to implement the new features so that UPNs did not have to be changed. Phase 2 was the ConfigMgr/Intune solution - guess what - UPNs now had to be changed. It's a real shame because Alternate Login IDs are a cracking new feature.
Friday, 22 August 2014
Direct Access: High Availability
Back to Direct Access main menu
DirectAccess has become a vital resource in many enterprise environments. We implement High Availability for technologies like SQL and Exchange so why should DirectAccess be any different? The good news is that it's easy to do so.
We've previously deployed a single server DirectAccess solution (lets call this server RAS1). Then we moved the NLS to a remote web server. Now we will implement HA for the solution. The following are the basic steps.
1. Add NLB feature to RAS1
3. Add Remote Access role and NLB feature to RAS2
4. Export IPHTTPS listener certificate from RAS1 and import to RAS2
Export certificate from RAS1
Import to RAS1
5. Virtual NICs
Enable MAC spoofing
Enable MAC spoofing on the virtual NICs of RAS1 and RAS2
Second NIC
You can implement this solution with a single NIC per server. However it is better practice to use two. The second NIC, for NLB communication, should be configured in separate subnet with no default gateway.
6. Enable Load Balancing
Launch the Remote Access Management console on RAS1.. Open the configuration.
On the bottom right of the window select "Enable Load Balancing".
The "Enable Load Balancing" wizard is launched. Click Next.
Choose NLB as the cluster method (note that you can configure the solution to use an external load balancer).
Enter an available IP address. The wizard is quite smart here. It knows that DirectAccess is already working with a single server solution (RAS1). DNS records and firewall rules have been created and we don't want to have to amend these. Therefore the wizard swaps the IP addresses.
The working dedicated IP address of RAS1 (DIP) becomes the Virtual IP address of the NLB cluster (VIP).
The new available IP address becomes the IP address of RAS1. Pretty clever.....
Verify the settings and "Commit".
Review progress.
Click Close to return to the wizard.
Verify success and close the wizard.
See what has happened. A load balanced cluster has been created with a single node (RAS1).
Note that the IP address of RAS1 has changed.
7. Add second server to cluster
Now, on the bottom right of the Remote Access Management configuration window, choose "Add or Remove Servers".
Select "Add Server".
Browse to choose RAS2.
Ensure that the correct NIC is selected.
Verify the settings and click Add.
Close the wizard.
"Commit" the changes.
Verify progress.
Close the "Adding or Removing Servers" wizard.
See that the second node has been added to the load balanced cluster.
Verify that the nodes are operating correctly.
Issues Encountered
I encountered a couple of issues during this configuration.
Firstly the wizard did not seem to add both nodes to the NLB cluster. When I opened the Network Load BaIancing Manager I noticed that only one node was present. I had to add the second node manually.
Also, my DirectAccess solution broke after I introduced NLB. I found that this was due to the fact that my customer had a series of firewalls with some kind of one-to-one NATing throughout. This played havoc with the NLB traffic. This was solved by introducing Dynamic NAT rules.
DirectAccess has become a vital resource in many enterprise environments. We implement High Availability for technologies like SQL and Exchange so why should DirectAccess be any different? The good news is that it's easy to do so.
We've previously deployed a single server DirectAccess solution (lets call this server RAS1). Then we moved the NLS to a remote web server. Now we will implement HA for the solution. The following are the basic steps.
- Add NLB feature to RAS1
- Build new Windows 2012R2 Server RAS2
- Add Remote Access role and NLB feature to RAS2
- Export IPHTTPS listener certificate from RAS1 and import to RAS2
- Enable MAC spoofing on virtual NICs
- Enable Load Balancing
- Add second server to Load Balanced cluster
1. Add NLB feature to RAS1
3. Add Remote Access role and NLB feature to RAS2
4. Export IPHTTPS listener certificate from RAS1 and import to RAS2
Export certificate from RAS1
Import to RAS1
5. Virtual NICs
Enable MAC spoofing
Enable MAC spoofing on the virtual NICs of RAS1 and RAS2
Second NIC
You can implement this solution with a single NIC per server. However it is better practice to use two. The second NIC, for NLB communication, should be configured in separate subnet with no default gateway.
6. Enable Load Balancing
Launch the Remote Access Management console on RAS1.. Open the configuration.
On the bottom right of the window select "Enable Load Balancing".
The "Enable Load Balancing" wizard is launched. Click Next.
Choose NLB as the cluster method (note that you can configure the solution to use an external load balancer).
Enter an available IP address. The wizard is quite smart here. It knows that DirectAccess is already working with a single server solution (RAS1). DNS records and firewall rules have been created and we don't want to have to amend these. Therefore the wizard swaps the IP addresses.
The working dedicated IP address of RAS1 (DIP) becomes the Virtual IP address of the NLB cluster (VIP).
The new available IP address becomes the IP address of RAS1. Pretty clever.....
Verify the settings and "Commit".
Review progress.
Click Close to return to the wizard.
Verify success and close the wizard.
See what has happened. A load balanced cluster has been created with a single node (RAS1).
Note that the IP address of RAS1 has changed.
7. Add second server to cluster
Now, on the bottom right of the Remote Access Management configuration window, choose "Add or Remove Servers".
Select "Add Server".
Browse to choose RAS2.
Ensure that the correct NIC is selected.
Verify the settings and click Add.
Close the wizard.
"Commit" the changes.
Verify progress.
Close the "Adding or Removing Servers" wizard.
See that the second node has been added to the load balanced cluster.
Verify that the nodes are operating correctly.
Issues Encountered
I encountered a couple of issues during this configuration.
Firstly the wizard did not seem to add both nodes to the NLB cluster. When I opened the Network Load BaIancing Manager I noticed that only one node was present. I had to add the second node manually.
Also, my DirectAccess solution broke after I introduced NLB. I found that this was due to the fact that my customer had a series of firewalls with some kind of one-to-one NATing throughout. This played havoc with the NLB traffic. This was solved by introducing Dynamic NAT rules.
Thursday, 21 August 2014
Direct Access: Move NLS to remote web server
Back to Direct Access main menu
Previously we implemented Direct Access in five easy steps using a single server. In production additional configuration is required to implement a best practice solution.
The Network Location Server is a key component of DirectAccess. Its purpose is to detect whether computers configured as DirectAccess clients are located in the corporate network. When clients are in the corporate network, DirectAccess is not used to reach internal resources. Instead, clients connect to internal resources directly.
The network location server is simply a Web site with an HTTPS server certificate. It should be located on a remote web server (not the DirectAccess server - which has the Remote Access role). It is also good practice to have multiple NLS servers in a Highly Available configuration.
This blog post demonstrates how to move the NLS configuration to a remote web server.
First you need a web server. Install IIS as normal.
Next you will need an SSL certificate. Note that you can use a self-signed certificate when the NLS is co-located with the DirectAccess server. However you can't on a remote web server.
In my example I used my Internal CA and requested a certificate using the Web Server template (using the Certificates Snap-In).
See that further information is required.
The Common Name is the FQDN of the web server (eg nlsweb.contoso.local).
Web Server certificate has been installed.
Add https to site binding and configure to use the new certificate.
Now, back at the DirectAccess server, open the Remote Access Management console.
Edit the Infrastructure Servers section (Step 3).
Enter the URL of the remote server (in the format https://nlsweb.contoso.local) and click to Validate. You will not be able to continue if the URL is incorrect and you cannot validate.
Apply the new settings.
Close the wizard.
Now test your configuration. DirectAccess clients should still be able to connect as normal.
Previously we implemented Direct Access in five easy steps using a single server. In production additional configuration is required to implement a best practice solution.
The Network Location Server is a key component of DirectAccess. Its purpose is to detect whether computers configured as DirectAccess clients are located in the corporate network. When clients are in the corporate network, DirectAccess is not used to reach internal resources. Instead, clients connect to internal resources directly.
The network location server is simply a Web site with an HTTPS server certificate. It should be located on a remote web server (not the DirectAccess server - which has the Remote Access role). It is also good practice to have multiple NLS servers in a Highly Available configuration.
This blog post demonstrates how to move the NLS configuration to a remote web server.
First you need a web server. Install IIS as normal.
Next you will need an SSL certificate. Note that you can use a self-signed certificate when the NLS is co-located with the DirectAccess server. However you can't on a remote web server.
In my example I used my Internal CA and requested a certificate using the Web Server template (using the Certificates Snap-In).
See that further information is required.
The Common Name is the FQDN of the web server (eg nlsweb.contoso.local).
Web Server certificate has been installed.
Add https to site binding and configure to use the new certificate.
Now, back at the DirectAccess server, open the Remote Access Management console.
Edit the Infrastructure Servers section (Step 3).
Enter the URL of the remote server (in the format https://nlsweb.contoso.local) and click to Validate. You will not be able to continue if the URL is incorrect and you cannot validate.
Apply the new settings.
Close the wizard.
Now test your configuration. DirectAccess clients should still be able to connect as normal.
ConfigMgr 2012 / SCCM 2012 SCEP Troubleshooting
Back to Endpoint Protection menu
Back to ConfigMgr 2012 menu
The best SCEP troubleshooting information that I've encountered can be found in a single TechNet blog post by Mary Hutson. It is a collection of the top Microsoft Support solutions for the most common issues experienced when using System Center 2012 Endpoint Protection and it is updated quarterly.
It contains information and solutions in the following areas:
You can find the blog post here.
http://blogs.technet.com/b/topsupportsolutions/archive/2014/02/04/top-support-solutions-for-system-center-endpoint-protection-2012.aspx
Back to ConfigMgr 2012 menu
The best SCEP troubleshooting information that I've encountered can be found in a single TechNet blog post by Mary Hutson. It is a collection of the top Microsoft Support solutions for the most common issues experienced when using System Center 2012 Endpoint Protection and it is updated quarterly.
It contains information and solutions in the following areas:
- Solutions related to malware not cleaned, detected, or quarantined
- Solutions related to SCEP Client Problems
- Solutions related to Definition deployment issues
- Solutions related to Client Policy editing, policy deployment, or policy adherence
- Solutions related to Client Application compatibility (another application has problems)
You can find the blog post here.
http://blogs.technet.com/b/topsupportsolutions/archive/2014/02/04/top-support-solutions-for-system-center-endpoint-protection-2012.aspx
Subscribe to:
Posts (Atom)