Intune - Android Custom Notifications and Play Lost Device Sound

Introduction

Recently I completed my half yearly task of rebuilding my MECM lab.  I do rely on evaluation licenses for most of my Microsoft products, and so it does make sense to rebuild on a regular basis for this reason.  In addition, building a MECM lab is always a great knowledge refresher.  I did enable MECM Cloud Attach, which of course meant I did have an instance of my old friend, Intune.  Now recently I have been working in air gapped environments - and this means no hands on Intune fun for a while.  I thought I would take the opportunity of refreshing my knowledge about this great product.  I did follow Jonathan Edwards great video on how to enable and manage Android enrolments into Intune.

How to Manage Android Devices in Microsoft 365 Using Intune

Having only recently purchased for myself a Lenovo tablet with Android v15 installed - I did ensure this device became enrolled into my Intune instance. Doing some experimentation (playing) I found two features so interesting I really did have to write about them.  Firstly let's look at the Custom Notifications feature.

Custom Notifications

So you would like to send an urgent message out to all your staff members, using their phones or tablets?  Perhaps warning of a security event or a reminder to fill in timesheets!  Intune has the Custom Notifications feature precisely for this sort of requirement.  Firstly, you will need to ensure a few settings are applied to your tablets or phones.  In my case I had to enable Notification permissions for both Intune and the Company Portal Apps.

Secondly, I needed to enable Notifications history.

The next step is to create a group in Intune.  Add into this group the users or their devices or both (I had more success when adding both user and the device).  In this case I created a group called Global Communications.

Next, Navigate to Tenant Administration\Custom Notifications.  Enter in your message and click on Next.

Click on Add Group and then place and tick next to your chosen group and then click on Select.

Click on Next and then Create.

After a few minutes your device will emit an attention chime and you can view the message on the lock screen.

In addition, you can view the message in your Intune Portal under Organization messages.

Play Lost Device Sound

Another fun feature is the ability to send a jingle from the Intune portal to the remote Android device.  A build engineer with dozens of identical tablets on his desk may find this very useful.  Can't find the tablet showing an issue in the portal?  Just send it the Play Lost Device Sound command and it will light up playing the jingle.  Likewise if a user knows the Android is near at hand but cannot find it - then this command may assist with tracking the device down.

In the Intune portal locate the device under the devices node.  Click on Play Lost Device Sound.

When prompted select the number of minutes you would like the jingle to play.

In this case I select one minute.  When clicking on Yes the targeted device will play the Lost Device Jingle.

If you do not chose to stop the sound you are presented with an information method as follows.

Conclusion

Intune is a great product and evolving all the time with great features.  I hope you enjoyed reading about the Custom Notifications and the Play Lost Device Sound features in this little blog.  I wish you similar success with your own experimentations.

HP Device Manager - Failed to connect to the Master Repository Controller

Introduction

You may notice the following error after signing into the HP Device Manager console:

Error Details: Failed to connect to the Master Repository Controller.  Maximum number of retries reached.

The Master Repository Controller is a component that manages payload content and synchronizes this content to child repositories.  Many tasks can be corrupted if there is an issue with the Master Repository Controller. For instance the Update Agent task may fail.  Perhaps the most common tasks are Capture and Deploy Files operations.  Follow the steps in this article to fix the Master Repository Controller connection issue.

Fix 1: Check the Service

Run services.msc and ensure that the HP Device Manager Master Repository Controller service is running.  Start the service if it is in a stopped state.

Fix 2: Reinstall the HP Device Manager Master Repository Controller service

In some cases the service may start but then stop a few minutes or seconds later.  In this case consider reinstalling the HP Device Manager Master Repository Controller service.  Your database and configuration will be retained.

You can initiate a reinstall by running HPDMMasterRepositoryController.exe.  The default location for this will usually be c:\swsetup\HP Device Manager 5.0.  After double clicking on this file you will be prompted to uninstall the service.

Click on Yes to uninstall the service.  When this is completed, once more double click on HPDMMasterRepositoryController.exe and the service will be reinstalled.  If there is still an issue then you should upgrade the installation of HP Device Manager to the latest version, if a newer version does exist.

Fix 3:  Recreate the Authentication Files

In this fix we stop the HP Device Manager Master Repository Controller service, make a backup of the authentication files and then delete the authentication files.

Copy the following files to a safe location.

<HP Device Manager Installation Directory>\HP Device Manager\\MasterRepositoryController\client.crt

<HP Device Manager Installation Directory>\HP Device Manager\MasterRepositoryController\controller.crt

<HP Device Manager Installation Directory>\HP Device Manager\MasterRepositoryController\controller.key

Also make a backup of the following file.

<HP Device Manager Installation Directory>\HP Device Manager\Server\Bin\hpdmskey.keystore

The next step is to stop the HP Device Manager Master Repository Controller service.

When the service is stopped delete the files.

<HP Device Manager Installation Directory>\HP Device Manager\\MasterRepositoryController\client.crt

<HP Device Manager Installation Directory>\HP Device Manager\MasterRepositoryController\controller.crt

<HP Device Manager Installation Directory>\HP Device Manager\MasterRepositoryController\controller.key

<HP Device Manager Installation Directory>\HP Device Manager\Server\Bin\hpdmskey.keystore

Next, restart the HP Device Manager Master Repository Controller service.  The deleted files will be recreated.  Sign in to the HP Device Manager Console and click on Gateways and Repositories.  In the left hand column click on Repositories and then double click on the Master repository.  Click on Summary and then  click on Test Repository.  Verify that the repository function test has revealed no errors.

Conclusion

HPDM is a bit of a niche product.  Oftentimes issues will occur and the usual Google search will not gift you with a fix.  I hope the instructions in this little blog resolve your master repository controller connection issue and I wish you every success using HPDM to manage your HP ThinPro thin clients.

HP ThinPro - BareMetal with HP ThinUpdate

Introduction

Do you want to reimage your ThinPro Thin Client device?  Perhaps you would like to update it to the latest ThinPro release without using a HP Device Manager template. A great way to achieve this is to create a bootable USB key using the free HP ThinUpdate tool.  Using the ThinUpdate tool you will select a ThinPro image for your Thin Client model.  The tool will wipe an inserted USB key, format it and download onto it the selected ThinPro image.

Install the HP ThinUpdate tool.

The ThinUpdate tool can be downloaded from the Software and Drivers section of support.hp.com.  The actual tool is not Thin Client model specific, but if you do enter in your model you will be directed to a location where you can download the tool.  One such location, for the T655 is:

https://support.hp.com/gb-en/drivers/hp-elite-t655-thin-client/2101137492

Download the tool and double click on the downloaded executable (in this case sp156567.exe).

Click Next on the wizard start page.  Accept the licence agreement and click on Next.

On the Location to Save files page, click on Change if you would like the .msi file saved to a different location.  Click on Next.  After the installer file is extracted double click on it to start the installation wizard.  Click Install on the Ready to install  HP ThinUpdate page.  Click Finish on the HP Thin Update setup wizard page.

Create a USB BareMetal install USB key

Insert your USB key into the device on which you installed the HP ThinUpdate tool - ensure you have copied any important files on it to a safe location.  Open the HP ThinUpdate tool from the Windows menu.  If prompted agree to download any updates.  Select Download a thin client recovery image to a local storage USB flash drive. 

The Image Downloads window appears.  In the Platform pull down menu select your thin client model.  In this case I select the T630.  In the Operating system pull down menu select the version of ThinPro that you would like to install.  In my case I select Thinpro 8.1.0  In the Images pull down menu select the ThinPro image you would like to install.  In my case I select the ThinPro 8.1.0 SP6.2 4096MB x64 Image.  Ensure that the USB flash drive appears in the Target area and then select Create.

A warning message appears advising that all data from the USB flash drive will be erased.  Click on Yes.

The USB flash drive is formatted and the download begins.

A completed successfully window appears when the USB key creation process finishes.

Perform a ThinPro BareMetal build on the HP Thin Client

The next sequence of instructions may be different, depending on your Thin Client model.

Insert your ThinUpdate USB key into the thin client.

Power on your device and click on ESC to enter the Startup Menu.  Click on Continue Startup.

The Loading UKit window appears.

The Imaging Tool main selection menu appears.  Select option 1 - Image Write Mode and press Enter.

The Image selection window appears.  Type in the number corresponding to the image you want to apply to the Thin Client device.  In my case I select Image 1 which is the ThinPro 8.1 SP 6.2 image.  Press Enter.

You will be presented with warning message and asked if you wish to continue.  Type Y for yes and click on Enter. The image writing process will take about 2-3 minutes to complete.

When the image operation has completed click on the Enter key to return to the main menu.

Click on 3 and then Enter to exit.

Remove the USB key and press Enter again.

After a few moments you will be at the hp ThinPro Continue Setup page.  Complete the wizard as required.

Conclusion

The HP ThinUpdate tool is very easy to use.  It only takes minutes to update or revert a Thin Client ThinPro OS to a factory reset state.  It is free to download as well.  Indeed there is a lot that is very pleasing about this useful little tool from HP.  I hope you have enjoyed reading this little blog and I wish you the same success in your Thin Client BareMetal reimaging tasks.

HP ThinPro - Deploy a Wallpaper Image

Introduction

HP Device Management (HPDM) is used to manage the HP Thin client running the ThinPro Operating system.  The ThinPro OS (Linux based) is a very secure environment.  I have been working with HPDM and HP ThinPro extensively for the past couple of years.  In the next series of blogs I will be discussing how to use HPDM to implement common OS tasks.  In this blog I will show you how to deploy a new wallpaper picture to your ThinPro estate.  The process has four steps:

1) Deploy the new wall paper image to a test device.

2) Set the new image as the desktop wallpaper on the test device.

3) Send a capture profile task to the test device.

4) Deploy the new profile to your pool of HP ThinPro devices.

Deploy the new wall paper image image to a test device.

You can start this by creating a local directory and copying the desired wallpaper image into this directory.  Do this on the HPDM server.  In my case I create a directory called FilesToSend, and I copy a picture of an Airbus aircraft into this directory.  

I then open the HPDM console and navigate to Manage Devices and right click on the test thin client, to which we are going to send the image.  We then select Send Task.

The Template Chooser windows appears.  Select File and Registry in the category column and select _File and Registry in the Template column and click on Next.

The Task Editor window appears.  In the Content tab click on Add.  The sub-task chooser window appears.  Click on Deploy Files and click on OK.  The Deploy Files window appears.  Click on Add from Local and select the wallpaper file.  In the Path On Device section enter in /tmp/.  

Click on OK and then OK.  Provide a name for the template, such as SendWallpaper and click on Generate on the Package Description Editor - Files to Deploy window.   

Click on OK to send the file to the test device.

Set the new image as the desktop wallpaper on the test device.

On the test ThinPro device click on the lower left hamburger and select Switch to Administrator and enter in the credentials when prompted.  Click again on the hamburger and select Control Panel.  Click on Appearance and then click on Desktop.  You will see a Theme drop down box - select Image and and then click on Choose a file.  In the Find a background image windows navigate to /tmp/ and select the sent image.  Click on Open and then Apply.

Send a capture profile task to the test device.

Now that we have sent the new wallpaper file to the test ThinPro device, and set this as the background wallpaper - we can capture this new configuration into a profile template.

In HPDM, right click on the test device and select Send Task....  The Template Chooser window appears.  In the left hand Category column select Settings.  In the right hand Template column select _Capture Profile.  

Click on Next.  The Task Editor window appears.  Enter in a name for the template such as Airbus Wallpaper and click on OK.

Deploy the new profile to your pool of HP ThinPro devices.

Having captured a new profile with a new wallpaper image, we can then deploy it at will to other ThinPro devices.  In the HPDM console navigate to Manage Devices.  In the right hand pane, select one or more ThinPro devices and click on Send Task.  The Template Chooser window appears.  In  the left hand column under Category select Settings.  In the right hand column under Template select the profile captured in the above section.  Click on Next and then OK to send the profile, with the new wallpaper image, to the selected ThinPro devices.

Conclusion.

The HPDM console can seem a bit confusing at first - however, as you perform more tasks you will become very comfortable very quickly.  It won't be long before you realise that indeed it is just as easy to manage these Linux based ThinPro devices as it is to manage your Windows devices.  I hope you have enjoyed this little blog and wish you much success in your own administrative tasks.

MECM with EHTTP and HSTS enabled on a DP

Introduction

Recently a penetration scan was done on a client's Microsoft Endpoint Configuration Manager's (MECM) environment.  The MECM security settings stipulated EHTTP rather than PKI security. EHTTP (Enhanced HTTP) secures client communication by using self-signed certificates.  Sometimes the overhead of using PKI certificates is not practical - for instance if automatic enrolment and renewal cannot be established.  EHTTP does secure communications when this situation exits.  Without a client PKI certificate, network access account or Windows authentication clients can securely download application content from distribution points.

And this was all good until the penetration scan revealed that the MECM Distribution Point was not in compliance with RFC 6797 - a vulnerability we needed to address.  This vulnerability states that the HSTS (HTTP Strict Transport Security) is missing from the HTTP server - that is, the MECM Distribution point.  HSTS is a security protocol that commands a browser to only communicate via HTTPS.  When HSTS is not activated the following attacks can occur:

1) Downgrade attacks: This is a cryptographic attack that can downgrade an encrypted connection to a lower-quality connect such as a cleartext connection.

2) Man in the Middle Attacks: This is a cyberattack in which direct communication between two entities is secretly compromised and a third entity is filtering and capturing the communication data.

3) Cookie hijacking: This is when the attacker steals HTTP cookies by listening on the communication between the two systems, thus gaining access to web browser data.

And so the begging question was this:  could we enable HSTS on a MECM distribution point configured to use EHTTP?  I found no definitive documentation answering this question.  The documentation I did find suggested HSTS could only be enabled on a site using PKI certificate authentication.  Further investigation was required.

Application download without HSTS and EHTTP.

Without enabling HSTS I cleared the Configuration Manager client cache and started a test install of a PSApp deployment toolkit package.  I then examined the datatransfer.log file on the client to determine the mode of transport the download used in the transaction.

The site communication was configured as per the following screen grabs.

As can be seen in the datatransfer.log file below the deployment download is initiated using http with redirection to port 80.

Application download with HSTS and EHTTP.

I then enabled HSTS on IIS on the MECM Distribution Point.

This was done by opening the IIS admin console and navigating to the Default Web Site.  It was then matter of clicking on HSTS in the actions column and enabling the feature, ensuring all options were selected.

I then opened a command prompt as administrator and ran the following command: iisreset.exe

On the test server I then cleared the MECM client caching by running control smscfgrc, clicking on the Cache tab and then clicking on Clear Cache

I then reinstalled the application within software center.  As can be seen from the DataTransfer.log file - the download takes place using HTTPS on port 443.

Conclusion

The tests here demonstrate that oftentimes what is expected in a given configuration is not always what is observed.  Enabling HSTS in this scenario should not have been possible when MECM is configured for EHTTP communications.  Astonishingly, forcing HSTSC on the IIS installation on the Distribution Points forces the MECM client to download application content using HTTPS on port 443 using self-signed certificates, almost as if the site is configured to use PKI certificates.  

A further dividend for us here is that the Penetration scan no longer detects the RFC 6797 vulnerability.

I hope you enjoyed this blog and I wish you much success in your own testing of HSTS with MECM using EHTTP.