Thursday, 30 May 2019

Deploying Intune Connector for AD with a web proxy

I'm working on a Windows AutoPilot solution for a customer this week. This is a hybrid AD solution and the devices will join both Azure AD and the corp AD. I had previously deployed the Intune Connector for Active Directory for testing purposes and it's pretty straightforward. However it's a little different in an enterprise environment. 

I successfully installed the connector on a Windows Server 2016. However the connector never appeared in Intune. There were many errors in the ODJ Connector event logs

"We are unable to complete your request because a server-side error occurred. Please try again. [Exception Message: \"DiagnosticException: 0x0FFFFFFF. We are unable to complete your request because a server-side error occurred. Please try again.\"] [Exception Message: \"Failed to get a value for Key: OdjServiceBaseUrl\"] [Exception Message: \"The given key was not present in the dictionary.\"

The proxy log files showed no activity so clearly I needed some way to ensure that the tool was directing traffic to the proxy.

This document discusses using the tool with on-premise proxies

However, it’s really not useful as it just recommends bypassing the proxy and configuring the tool (ODJConnectorUI.exe.config and ODJConnectorSvc.exe.config) to do that. We all know that is not practical. Most enterprise customers won’t allow you to bypass the proxy so I needed a way to make the Intune Connector use the proxy.

  • Configuring the proxy in IE does not work
  • Using “netsh winhttp set proxy” does not work 
Michael Niehaus worked on this and provided the code to add to the config files.

It worked perfectly and the Intune Connector was created (you have to restart the Intune ODJConnector Service).

The documentation will be updated accordingly. 

This is the code snippet that should be added to both the ODJConnectorUI.exe.config and ODJConnectorSvc.exe.config files.

<?xml version="1.0" encoding="utf-8" ?>
      <proxy usesystemdefault="false" proxyaddress="http://contoso-proxy:3128" />  

    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" />


 It was good to see successful communication in the event logs

It is important to include http:// in the proxy address. We didn't at first and we spotted the following in the event logs:

":"We are unable to complete your request because a server-side error occurred. Please try again. [Exception Message: \"DiagnosticException: 0x0FFFFFFF. We are unable to complete your request because a server-side error occurred. Please try again.\"] [Exception Message: \"The ServicePointManager does not support proxies with the scheme.\"]" 

I hope this helps someone to configure the Intune Connector for Active Directory behind a web proxy.

Until next time....

Tuesday, 21 May 2019

Renew Cloud Management Gateway Certificate

It's always a good idea to purchase an SSL certificate for as long as possible to minimize renewal times. They're a pain, right. We're always a little unsure about exactly how to renew the cert. However I have quite a few customer CMGs with one year SSL certificates and they are expiring soon so I thought I better figure out the renewal process.

Firstly, you cannot see that the CMG certificate is expiring in the ConfigMgr console. I've asked the Product Group to add this as a Management Insight or at least to expose the expiration date in the console.

Usually the only way you will be reminded about the expiring certificate will be an email from your certificate vendor (DigiCert in my case).

DigiCert remind you when the certificate is expiring in 90 days. There is no penalty for renewing early. When you renew early, DigiCert adds the remaining time from your current certificate to your new certificate (up to 3 months). You don't have to wait until the day before your certificate expires just to get your money's worth.

I have received the email and can now see the "Renew now" option in the DigiCert portal.

Should I renew the cert or generate a new one?

Technically, when you renew a certificate, you are purchasing a new certificate for the domain and company. Industry standards require Certificate Authorities to hard code the expiration date into the certificates. When a certificate expires, it is no longer valid and there is no way to extend its life. So, when you "renew" your certificate, DigiCert must issue a new one to replace the expiring one. So it's not really a renewed certificate.

What does renewing mean then?

To make renewing a certificate easier, DigiCert (and other vendors) automatically includes the information from the expiring certificate in the renewal wizard. However, because you're ordering a new certificate, you can update any of the information during the order process, if needed. Note that if you change any of your organization’s information (location, etc.) you may need to provide new validation documentation to verify the changes. 

I decided to go for a new certificate.

I generated a new CSR using the vendor tool with the same details as the previous certificate.

The certificate was approved and I could download the .crt file.

I imported the .crt file into the tool to complete the process and associate with the private key.

Then I was able to export the certificate to a usable format.

Selected .pfx with the private key, entered a password......

....and the new certificate was ready.

So what now? Is it just as simple as replacing the certificate in the properties of the CMG? Yes, it is. Simply browsed to the new certificate, entered a password and clicked Apply.

You can monitor activity in the Operations logs in Azure.

Finally you can run the CMG Connection Analyzer to make sure that everything is OK.

Will the world end if the certificate expires?

Not really. Your internet clients won't break and will still have the same functionality. You just won't be able to manage them over the internet though. When you eventually add a new certificate you will not have to take any action on the clients.

I hope this helps. Until next time.....

Thursday, 2 May 2019

First look at Intune Win32 app dependencies

The ability to deploy Win32 apps using the Intune Management Extension really improved the quality of Intune app deployment to Windows 10 devices. Microsoft have now taken this one step further with the release of Win32 app dependencies this week. 

What are app dependencies?

App dependencies are applications that must be installed before your Win32 app can be installed.

How many dependencies can I have?

There is a maximum of 100 dependencies, which includes the dependencies of any included dependencies, as well as the app itself.

What kind of dependencies can I configure?

You can add Win32 apps as dependencies for other Win32 apps, only after your Win32 app has been added and uploaded to Intune. Once your Win32 app has been added, you'll see the Dependencies option on the blade for your Win32 app.

Do I have to assign dependent apps to users or devices?

You can choose whether or not to install each dependent app automatically. By default, the Automatically install option is set to Yes for each dependency. By automatically installing a dependent app, even if the dependent app is not targeted to the user or device, Intune will install the app on the device.

How does it work?

Once the Win32 app has been uploaded to Intune you will see two new options - Dependencies and Dependency Viewer.

Select Dependencies.

Select Add to add a dependency.

You are presented with a list of available Win32 apps. Select one to be a dependent app.

Choose Select.

Choose if you want the dependency to automatically install (without being assigned). Choose Add to finish the process.

Now select the Dependency Viewer to see the active dependencies. I have a simple example here but this will be very useful to see all the dependencies and even sub-dependencies.

You can remove a dependency by clicking on the ellipses (three dots) at the end of the row in the dependency list.

What else should we know?
  • The end user will see Windows Toast Notifications indicating that dependent apps are being downloaded and installed as part of the Win32 app installation process.
  • If you choose not to Automatically install a dependency, the Win32 app installation will not be attempted.
  • Each dependency will adhere to Intune Win32 app retry logic (try to install 3 times after waiting for 5 minutes) and the global re-evaluation schedule.
  • Dependencies are only applicable at the time of installing the Win32 app on the device.
  • Dependencies are not applicable for uninstalling a Win32 app.
For me this is a very useful new feature and will help to ease the transition to modern management.

Until next time....

Wednesday, 10 April 2019

Deploying CMG with Enhanced HTTP (my experience)

I've configured a number of Cloud Management Gateways in the past, both for customers and in lab environments. In each case I've added a Management Point and configured it to use HTTPS. I've had to do that to manage Windows 7 clients over the Internet using traditional PKI. Recently I rebuilt my ConfigMgr lab to prepare demos for MMS 2019. As I'll just be using Windows 10 it has given me the opportunity to try Enhanced HTTP for the first time. I had a few problems to figure out along the way (with the help of Nick Hogarth, thanks Nick) but, now that it is configured correctly, everything works really well.

So what is Enhanced HTTP all about?

Traditionally we've used PKI to secure communication in ConfigMgr environments. Microsoft still recommends using HTTPS communication for all Configuration Manager communication. However they recognize that it can be challenging for some customers due to the overhead of managing PKI certificates. By using Azure AD integration we can simplify the process using Enhanced HTTP. In this scenario Azure AD-joined devices can communicate with a management point configured for HTTP. The site server generates a custom certificate for the management point allowing it to communicate via a secure channel. You can read about it here

The ConfigMgr admin doesn't need to do any IIS configuration as this is done in the background. We'll see that shortly.

Enhanced HTTP implementation steps

There are a number of steps which I implemented as follows.

Management Point configured for HTTP client communication

Enable the site option to Use Configuration Manager-generated certificates for HTTP site systems.

The SMS Role SSL Certificate was automatically configured and bound to port 443.

Onboard the site to Azure AD for cloud management

Using the Azure Services wizard.

Configure Azure AD User Discovery

Configure Hybrid AD Join

I was using domain joined devices for testing so I needed to configure Hybrid AD Join. Hybrid AD Join is configured using Azure AD Connect. A Service Connection Point is created during the process.

"Configure device options" was selected.

"Configure Hybrid Azure AD Join" was selected.

The SCP was created.

No further action should have been required because, once Hybrid Azure AD Join is enabled, devices will automatically join to Azure AD by default from Windows 10 Version 1607.

What issues did I experience?

I experienced a couple of issues during the process. In each case it's because I had forgotten to do something.

Firstly my test client could not be detected on the Internet. There were several errors in the CcmMessaging and LocationServices log files.

[CCMHTTP] ERROR: URL=http://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/ccm_system/request, Port=0, Options=1248, Code=87, Text=<null>

Successfully queued event on HTTP/HTTPS failure for server 'GERRYHAMPSON.EMSLAB.IE'.

Post to http://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/ccm_system/request failed with 0x87d00231.

CCMHTTP] ERROR: URL=https://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/SMS_MP/.sms_aut?SITESIGNCERT, Port=0, Options=1248, Code=0, Text=CCM_E_NO_CLIENT_PKI_CERT

Raising event:
instance of CCM_CcmHttp_Status
 ClientID = "GUID:76F79FF6-FA18-4E15-AA2F-9A4E71711ACC";
 DateTime = "20190410064418.902000+000";
 HRESULT = "0x87d00454";
 ProcessID = 3104;
 StatusCode = 0;
 ThreadID = 5368;

Also the CMG Analyser failed (it was OK when run against a certificate but not against an Azure AD User).

Failed to get ConfigMgr token with Azure AD token. Status code is '403' and status description is 'CMGConnector_Un-authorizedrequest'.
A possible reason for this failure is the CMG connection point failed to forward the message to the management point. The management point returned the following error: 'Un-authorizedrequest'. Check the specified Azure AD user is successfully discovered.


I had to figure out what was wrong and this is where Nick helped me. First I looked at the CMG Analyzer error. It looked pretty clear. "Check the specified Azure AD user is successfully discovered".

Also I could see errors in the CCM_STS.log file on the site server.

AAD user with ID 26800541-daf1-4334-aca0-c1a7d5d25a72 and SID S-1-5-21-3695679697-2106157007-715799775-1106 is not completely discovered

I knew that Azure AD Discovery was enabled but I still couldn't see any users. After I rebuilt the site I had forgotten to enable AD User Discovery. This is also a requirement.

I did that and could successfully run the analyser.

I also had an issue with the test device. It should have automatically joined Azure AD but it didn't.

See the output of the dsregcmd /status command. AzureADJoined: NO

The output also gave more information: The device object by the given ID is not found.

I couldn't understand that. I had configured Azure AD Join in Azure AD Connect which should have synchronized all the computer objects to Azure AD.

I had a look at the Azure AD Connect configuration again and realized that I had forgotten to select the Workstations OU to synchronise. I didn't need to before. I was only interested in users at the time.

After synchronization the device joined to Azure AD.

No more errors in the LocationServices.log file.....

...and in the ConfigMgr console the device was Online over the internet.

It could also be seen as a Hybrid Azure AD joined device in Azure AD.

I hope this helps someone else to configure the Enhanced HTTP solution. Until next time......

Tuesday, 9 April 2019

CMG Connection Analyzer error - NameResolutionFailure

This week I've been rebuilding my ConfigMgr lab in preparation for demos at MMS 2019. Last night I added the Cloud Management Gateway. I had all the prerequisites in place. I had my certificates already and the CNAME for my external domain was configured. You can read about the certificate and CNAME requirements here

All looked good with the CMG.

There were no errors in the CloudMgr.log file.

The Azure Cloud Service had been created.

My first hint of a problem was the CMG Connection Point status, which remained Disconnected. I figured it was time to run the trusty CMG Analyzer. It's brilliant for pin-pointing where the issue is.

Oops - a lot of errors there.

First one - Failed to connect to the CMG service. Unexpected response status code is NameResolutionFailure. For more information, see SmsAdminUI.log.

Configuration version of the CMG service should be 4.
Failed to get CMG service metadata. For more information, see SmsAdminUI.log.

Connection status of CMG connection point 'ConfigMgr.GH.LOCAL' is 'Not Connected'. Routing to primary site 'GH1' may not be fully functional. For more information, see SMS_CLOUD_PROXYCONNECTOR.log on the CMG connection point.

Failed to test the CMG channel. Check SmsAdminUI.log for more details.

Let's have a look at the log files.

The SmsAdminUI.log file doesn't help very much.

Neither does the SMS_CLOUD_PROXYCONNECTOR.log file. There is nothing there to help me.

So what was the first error again? Failed to connect to the CMG service. Unexpected response status code is NameResolutionFailure.

I previously configured a CNAME record so I didn't quite understand that.

That was the problem - no CNAME record.

This is a test domain and someone had been messing around with the DNS records. The CNAME record had been deleted. I added it back.

Then the CNAME lookup was successful (this took about 8 hours).

The CMG Connection Point connected with no further action from me.

The CMG Analyser then executed perfectly. We're back in business. 

I hope this helps. Until next time.....