Hi All,

In May Microsoft released the App Wrapping tool for Android ( https://www.microsoft.com/en-us/download/details.aspx?id=47267 ) which is another great milestone in the MAM capabilities of Microsoft Intune.

I saw already some blogs where the blogger just executes the Powershell Wrapper script to create a new wrapped APK file. So far so good but that’s not enough that will never work… you know why?

Android wrapped Apps need to be signed and that’s a requirement of Android.

If we talk about signing we need a private key that needs to be created. You can do this by executing the following keytool command, which is part of your Java Installer:

keytool -genkey -v -keystore my-release-key.keystore
-alias alias_name -keyalg RSA -keysize 2048 -validity 10000

More info can be found here: http://developer.android.com/tools/publishing/app-signing.html#signing-manually

Once you have generated the private key, it’s time to use the App Wrapper with the following command line:

PS C:\Program Files (x86)\Microsoft Intune Mobile Application Management\Android\App Wrapping Tool> invoke-appwrappingtool -inputpath <path>\Notepad.apk -outputpath <path>\notepad_wrappedv2.apk -keystorepath "C:\Program Files (x86)\Java\jre1.8.0_45\bin\<keystorename>.keystore" -keyalias <aliasname> –SigAlg SHA1withRSA

If you execute this you will be prompted for the KeyStorePassword and KeyPassword which you have generated during the procedure to create your private key.

If everything goes well you will see after a while (depending on the size of your app) that your app is wrapped successfully.

So now we have a wrapped APK file that we can distribute with Configuration Mananger (CM) or Intune. In this example I use the Hybrid.

You link a MAM policy to your deployment:

You install the App form the SSP and voilà:

Attentive people noticed probably a “strange” switch in the command line: –SigAlg SHA1withRSA

You need this switch if you wrap applications on Android versions earlier than 4.3 Jelly Bean as they do not support apps signed by SHA256 and the App Wrapper is attempting to use the keystore’s default signing which is “SHA256withRSA”.

If you use the parameter “–SigAlg SHA1withRSA” you will be unblocked.

Hope you liked it!

Till next time

Nico Sienaert (@nsienaert)

Hi All,

Very recenlty the Product Team announced that the new Azure AD Connection Health is GA.

In a mobility world AD FS plays a very important role regarding Identity and Single SignOn. Thanks to this new Azure AD Premium service you can keep control of your cloud and on-premise identity infrastructure.

The issue:

When installing the agent I saw the following error:

After investigating the install logs I found this self-explaining error:

Looking into the install log file it’s an error 500, meaning that the server could be reached but is sending back an internal error :

System.Net.WebException: The remote server returned an error: (500) Internal Server Error.

   at System.Net.HttpWebRequest.GetResponse()

   at Microsoft.Identity.Health.Common.RestRequest.SendJsonData(HttpMethod httpMethod, String uri, String accessToken, Object content, X509Certificate2 clientCertificate)

   at Microsoft.Identity.Health.Common.Clients.PowerShell.ConfigurationModule.RegisterADHealthAgent.RegisterServiceIfNotExist(String serviceTypeName, String serviceSignature)

   at Microsoft.Identity.Health.Common.Clients.PowerShell.ConfigurationModule.RegisterADHealthAgent.ProcessRecord()

The solution:

After some trial and error the problem was the following.

As the agent is leveraging the Azure service you need to sign in into Azure service.

I used a Global Admin tenant account with @outlook.com. Despite of the fact the login was succesful I received the above error.

When logging in with a Global Admin account with domain suffix the installation finished successfully.

After some contact with the Product Team it appears indeed that @outlook.com, @hotmail.com,… are not supported. You need to authenticate with a domain account.

They promised to workout a more clear error description in the future.

In meantime you know what to do!

Till next time,

Nico Sienaert (@nsienaert)

Hi All,

Since the release of the latest Configuration Manager Service Pack (CM12SP2 or CM12R2SP1) it’s possible to black and white list applications (aka Compliant and non-Compliant applications) on Windows Phone by creating Compliancy Rules through Configuration items.

Before you could already do something similar through OMA-DM but now you have a nice interface within the Configuration Manager Console without the need of looking up and modifying XML code. But that is still supported of course. You can find more info in one of my earlier blogs.

In this blog I’m not gonna go in detail on how you create such application lists other people did that already for you but I will focus more on how they actually work.

My attention was caught since I saw following errors in the Configuration Manager console when deploying such Applications lists.

An important word in the previous sentence is “Lists”. It’s of course supported to create several Lists but it’s not supported to deploy more than one List to a device or user. That can result in such conflicts.

If you send two Lists to a device, the first one that arrives will apply but as soon the second comes into the picture you will see a conflict error as above.

So the best practice if you want to allow (deny) Applications create one list and add software titles to that list or remove titles from the list.

Some detailed behaviour:

1) Application Black List 1 applied –> Apps disabled

2) Application Black List 2 applied –> Apps of list 1 stay disabled but a conflict error appears

3) Remove Deployment Application Black List 1 –> Apps of list 1 become “allowed” again and Apps of list 2 are now “Denied”.

4) Add a new title to Application Black List 2 –> New title will be disabled, all other Apps stay disabled.

But what if you want to Allow certain Applications and Block certain Applications on a device? Can you send two lists to a device in that case? The answer is NO.

The reason behind that is the fact that White lists are more restrictive than black lists. If one device has a white list, all apps outside of that list are blocked. So the Black list becomes redundant.

That’s also the reason why you have a Radio Button choice and not Check Boxes for instance:

To conclude, for Android and iOS you have a similar configuration. The main difference is that today this is only a reporting feature. So the non-compliant apps will not be blocked on the device itself but you will have reporting information.

Hope you liked it! Till next time!

Nico Sienaert (@nsienaert)

Hi All,

Wouldn’t it be great if you stay up-to-date about the latest Intune Service Notifications directly in the console without “RSS Feeding” you favorite blogs to stay informed about the latest and the greatest? Well, you can!

The configuration described below works for both standalone and hybrid setups.

For Hybrid setups, it’s today not possible to port these Notifications into the Configuration Manager console so you have to go the Intune Cloud console to see the list of Notifications or read the notification mails of course.

So yes, today this goes a bit against the Single-Pane-of-Glass approach but that’s what it is today.

Let’s go through the necessary steps:

Open the Intune console and go to the Admin Section and select “Recipients”.
Add the mail addresses of your choice that should receive NEW alerts.

Then go to the “Notification Rules” under the Admin Section and create a new Rule.

Important is that you select “Notices”.

Select all Device Groups

Select the recipients that should receive the notifications through mail

That’s it! Now you have to wait till you receive NEW notifications.

If you want to consult older notifications go to the Alerts Section and select the name of your Notice Notification rule.

Teaser: One important notification that is coming up, is the official announcement as from when iOS 7.1 will be required for running the Company Portal for all users (i.e. if you’re running an older version, it will prevent you from using the Company Portal until you upgrade to iOS 7.1+)

Till next time!

Nico Sienaert (@nsienaert)