Review: Hexnode MDM

I am on the hunt for a mobile device management solution (MDM) that can manage Windows 10 devices for free or for a low cost with little or no minimums.

If I can find this type of MDM solution, then I will use it to improve our ability to support client hardware for our small businesses customers.


The basic features that I’m most interested are pretty simplistic:

  • Profiles – allow for custom XML policies
  • Applications – inventory including version and the ability to remotely install an MSI (because I want to be able to remotely install teamviewer)
  • Updates – ability to view which OS updates have been installed
  • Antivirus – ability to view antivirus status
  • Encryption – ability to view encryption status
  • Organizational Groups – ability to establish a hierarchy for managing multiple customers

Nice to have would be:

  • Scripting – ability to run a powershell script
  • Encryption – ability to enforce encryption and harvest keys

Today, I signed up for a free trial of Hexnode. Hexnode has a low per device fee, fairly low minimums (15 devices per month), and allows for a 30 day free trial.

First Impressions

My device enrolled into Hexnode MDM

The UI is not my favorite, but that really wouldn’t make or break my opinion of a tool. My real complaint is that there isn’t as much device information available as I would have liked. On the good side, I could see the version of the build that is on the device including monthly patch. On the bad side, I couldn’t see simple things like drive space and importantly I couldn’t see whether or not the Defender AV was up to date.

I don’t need a fabulous UI, but I do need to see a minimal amount of information about the device in order to provide adequate management.

Can it do what I need it to do?

Here are the results for each task that I attempted:

Policies – There are quite a few Windows 10 policies available but unfortunately this didn’t include Windows Update or Microsoft Defender Settings. That is a non-starter.

Applications – This tool was great for deploying a simple MSI but the inventory didn’t show everything that was installed on the device which is a big issue.

Updates – I was not able to push any update settings. I could see the build version, but without the ability to force the clients to install updates automatically it would be difficult to manage a fleet.

Antivirus – I was not able to see the antivirus or definitions status for Defender and I couldn’t push any settings so it would be difficult to manage a fleet with this tool.

Encryption – I could see the encryption status which is great. I could also push encryption policies, however I could not escrow the key.

Scripting – There was no scripting option so I would have to find another way to do troubleshooting (for example – renaming the software distribution folder)

Organizational Groups – There wasn’t a way to establish an organizational hierarchy, but you could use dynamic groups to allow for management of multiple organizations within the same environment.

In Summary

My favorite thing about this solution is how quickly you can spin up a new environment. However, the minimum of 15 devices along with the missing management capabilities for Windows 10 makes this tool not a very good fit for managing small business. As always, my suggestion to MDM providers is that they should provide the ability to use Custom XML for robust policies management without the need for policy UI development.


Has anyone else tried this tool yet? Let me know what you think about it…

Configuring the LanmanWorkstation Policy CSP

I got a great question this week.

Just wondering how you got the LanmanWorkstation\EnableInsecureGuestLogons policy working. For the OMA-UTI I put ./Device/Vendor/MSFT/Policy/Config/LanmanWorkstation/EnableInsecureGuestLogons with the string <enable/> and it doesn’t seem to work

Anonymous Contributor

I went directly to the Microsoft website to see what it says about setting the policy.

https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-lanmanworkstation

Indeed, the documentation is rather misleading. It references ADMX even though this is not implemented as an ADMX policy.

Photo by Oladimeji Ajegbile on Pexels.com

Expected values for this policy are 0 or 1 and are of the type Integer.


That answer was enough for the Anonymous Contributor to get the policy working.

I hope that you find this helpful as well!

Review: Miradore MDM

I am on the hunt for a mobile device management solution (MDM) that can manage Windows 10 devices for free or for a low cost with little or no minimums.

If I can find this type of MDM solution, then I will use it to improve our ability to support client hardware for our small businesses customers.


The basic features that I’m most interested are pretty simplistic:

  • Profiles – manage Windows Updates settings you force auto installation of updates
  • Applications – inventory including version and the ability to remotely install an MSI (because I want to be able to remotely install teamviewer)
  • Updates – ability to view which OS updates have been installed
  • Antivirus – ability to view antivirus status
  • Encryption – ability to view encryption status
  • Organizational Groups – ability to establish a hierarchy for managing multiple customers

Nice to have would be:

  • Profiles – ability to push Custom XML settings (to configure any available CSP)
  • Scripting – ability to run a powershell script
  • Encryption – ability to enforce encryption and harvest keys

Today, I signed up for a free trial of Miradore. Miradore has a low per device fee, extremely low minimums ($10 per month), and allows for a 14 day free trial.

First Impressions

My device enrolled in Miradore MDM

I really like the simple, easy to navigate and understand UI. I was really excited at how easy it was to create a profile, deploy an MSI, and view detailed information about my device.

There is a LOT of information about the device in this system which I really fell in love with immediately. Everything that I could possibly want to know was at my fingertips with this solution.

Can it do what I need it to do?

Here are the results for each task that I attempted:

Policies – There are only 3 Windows 10 policies available – Windows Update, Exchange Email, and Passcode. This works as a bare minimum but would need to be built out to allow for more advanced configurations.

Applications – This tool was great for deploying a simple MSI and the inventory showed everything that was installed except for Universal Windows Platform applications. It can’t do more complicated application deployments and it can’t do UWP application deployments.

Updates – I was able to push the settings that I needed to configure updates though there was one thing broken in the UI (a drop-down list selection that showed Semi-Annual as an option for Branch Readiness which no longer exists so the policy failed to deploy until I changed it to Semi-Annual Targeted).

Antivirus – I was able to see the antivirus status and definitions status for Defender which is exactly what I need to see.

Encryption – I could see the encryption status. I could not enforce encryption or escrow the key.

Scripting – There was no scripting option so I would have to find another way to do troubleshooting (for example – renaming the software distribution folder)

Organizational Groups – There is a way to establish an organizational hierarchy which would allow management of multiple organizations within the same environment.

In Summary

I loved navigating this solution and the ideal pricing. This will likely be my choice of MDM for Windows 10. If Mirador adds the ability to use Custom XML for robust policies this tool will be unstoppable in the small business MDM space.


Has anyone else tried this tool yet? Let me know what you think about it…

Where’s the new Edge browser anyways?

Fresh back from some extremely enjoyable downtime over the holidays, I was alarmed to hear that the new Edge browser was going to be automatically installed on all of our PCs on January 15th through Windows Update. As much as I am looking forward to incorporating this new browser into our ecosystem, I was not at all ready to deliver such a big change to our users without managing the rollout in any way.


That said, it was a relief to find out that the browser was not going to be automatically deployed to MDM-managed PCs just yet. I’m all for Modern Management, but automatically deploying a new browser was pushing even me too far!

I thought that I would take the time to share a few thoughts that I have about the new browser.

Photo by Pixabay on Pexels.com

Positive Thoughts:

-It’s Chromium based so theoretically, all applications that currently run well in Chrome will run well in this browser.

-It will (eventually) come pre-installed on Windows 10 so there won’t be any need to do additional work to get it there.

-All of the policies that we’ve come to enjoy and expect for Internet Explorer and the old Edge browser will be available.

-If we can get all of our web applications working in the new Edge browser then theoretically we could block Chrome and Firefox installs thus reducing the need to manage those browsers as well. (I just point out now that I personally have nothing against Chrome. Chrome is a fantastic browser. It is the most used browser in the world of PCs!)

Photo by David Gomes on Pexels.com

Less Positive Thoughts:

-The CSP policies require the use of ADMX files. As you know from my previous post about Custom ADMX, it is kind of a chore to push policies like this. It’s not impossible, it’s just not as easy as the MDM policies that we currently have for IE and the old Edge.

-I’m not sure how quickly Add-ons will be made available. Since Chrome add-ons are so popular, this is a piece of the change that I’m still uncomfortable about. (Mostly due to lack of understanding on my part!)

-This whole browser thing is such a back office point of interest. Users really won’t know the difference between the old Edge and this new one except that (fingers crossed) it will work better and they won’t feel like they need to install Chrome on their business computers.


All in all, I’m exciting about 2020 and whether this new Edge browser can help us to trim down the number of browsers that we are supporting.

I hope that you are excited too!

Still have PCs on Windows 7?

If you are a small business without an IT department, you may be wondering what to do with PCs that are still running Windows 7. Windows 7 is going end of life very soon (January 14th, 2020), but there is still time for you to upgrade those PCs before they become unsupported. Being unsupported means that the operating system will no longer receive monthly quality and security updates and thus will be subject to ongoing issues and security threats.

I have a client that had a PC running Windows 7, so I used the instructions provided at the website below to upgrade a client’s PC earlier today.

https://www.bleepingcomputer.com/news/microsoft/you-can-still-upgrade-to-windows-10-for-free-heres-how/

I strongly suggest that you backup needed documents prior to following these steps. The upgrade did retain all of his documents post upgrade, but it is ALWAYS better to be safe than sorry.

The upgrade took a couple of hours. After the upgrade was completed a couple of things needed to be reconfigured (Printer driver, Email account repair).

Other than that, the upgrade was quite easy.

Best of luck with your remaining Windows 7 upgrades!

Using PSEXEC to Manually Test System Context Installs

MDMs and PCLM tools typically install applications in the System Context to allow all users of the PC to utilize the installed application.

Photo by Pixabay on Pexels.com

In order to accurately test (we call this a pre-flight test) packages prior to deploying them with your MDM, you will want to leverage PSEXEC. This will ensure that the manual installation test correctly mimics the System Context installation that will be performed by your MDM.

Install PSEXEC

• Download Sysinternals Suite from https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite
• Save Sysinternals.zip to Desktop
• Right-click on the ZIP and select Extract all then Extract

Copy PSEXEC apps into the System Folder

• Copy PSEXEC.exe and PSEXEC64.exe from the extracted folder to C:\Windows\System32 folder

Run the installation using PSEXEC
• Run Command Prompt as Administrator
• Type psexec \127.0.0.1 -i -s cmd.exe (this will open a new command prompt window; Note – for VMS type psexec -i -s cmd.exe)
• Type whoami to confirm that it is running as NT system user

Now you are ready to test the installation of your application using the command line which is now running in System Context.

Let me know if you have any questions or comments about these instructions!

3 Simple Steps to Deploying Win32 Applications with your MDM

Application management for Windows is hard. There is so much variation in the types of application packages that need to be deployed, moving from a PCLM tool to a modern tool like Workspace One can feel like TOO big of a job to do all at once.

Photo by JESHOOTS.com on Pexels.com

Never fear! All problems can be solved if you look at them in meaningful chunks.

There are three segments of the application deployment process that need to be addressed if you are going to make the move to Modern Management:

  1. Packaging
  2. Install Context
  3. Logging

Depending on how mature your organization is on these three aspects of application deployment, you may find moving to Modern Management easier than you thought.

Packaging

In our organization, we already had a very mature capability for Packaging our hundreds of natively installed applications.

What do I mean by mature? In our case, the bits that needed to be installed were wrapped in a script (e.g.- VBS, Powershell) which performs a series of pre-execution checks (for example – is the app already installed), executes the required installation command(s) in a specific sequence, and produces a log file. A standard format README file is also created for each package to indicate details such as installation command line, how to know when the installation is completed, installation context, reboot required, etc.

This consistency allows every application whether a single MSI, Executable, or combination or series including transforms and patches to be installed in a consisten and repeatable way. The process is executed the same way every single time.

Our MDM toolset is able to deploy application in ZIP format which aligns perfectly with the package approach that I just described. Please note that NOT ALL MDMs are able to deploy ZIP format. If you are using an MDM that does not support deploying ZIP format, then you will need to create a format that is supported by your MDM. A word of caution, creating a format such as MSI or EXE may or may not be supported by the vendor so ZIP is really a nice format to be able to use.

Install Context

The vast majority of applications should be installed in the System Context rather than the User Context. This eliminates concerns around whether the user of the PC has Administrative rights for installation of applications. It also ensure that the application is installed for All Users on the PC instead of for a single user. If you need to manually test whether the application successfully installs in System context, you will want to use PSEXEC to execute the installation. I will share more in a future post about how to use PSEXEC to install in System context manually.

95% or more of our application packages were built for installation in the System Context so that made our move to Modern Management easy. For situations where existing packages were being installed as User Context, we revised the packages to eliminate the need. In some cases, it was just a matter of deleting unnecessary code. In other cases, we leveraged Active Setup to copy needed files to user directories. If the packages could not be revised, then we leveraged a third-party tool to provide automatic elevation for User Context package installation on our PCs.

Logging

I am a very lazy coder so it is pretty funny for me to identify logging as the last item in the must haves list. It is important that the installation logs that are created by your packages write to a consistent location and that the location is easily accessible by a Standard User on the PC. No matter how great a package you have created, when you begin deploying a package with an Electronic Software Distribution tool you will see errors in installations and you will need quick access to the logs on a PC in order to determine the issue (which is typically within the package and not very often due to an issue with the tool).

I can’t tell you how many times I ‘ve been told, I tested in on my PC and it worked by an App Owner. The reality is that when you take that package and install it on 1,000 PCs you are going to run into scenarios that you did not account for in your package. Logging is essential to identifying these scenarios.

So that’s all that I wanted to share on this topic today. We were able to reuse hundreds of packages that were originally prepared for distribution using a PCLM tool and successfully deploy them with our MDM tens of thousands of times on Windows 10.

Create a Custom ADMX Policy

If your MDM does not provide a method for running scripts, you may want to create a Custom ADMX Policy to apply registry settings to your Windows 10 devices for situations where there are not CSPs available.

There are some limitations to what registry settings you can apply via Custom ADMX Policy. Policies are not allowed to write to locations within the System, Software\Microsoft, and Software\Policies\Microsoft keys, except for the following locations (Note – the following locations are ALLOWED):

  • Software\Policies\Microsoft\Office\
  • Software\Microsoft\Office\
  • Software\Microsoft\Windows\CurrentVersion\Explorer\
  • Software\Microsoft\Internet Explorer\
  • software\policies\microsoft\shared tools\proofing tools\
  • software\policies\microsoft\imejp\
  • software\policies\microsoft\ime\shared\
  • software\policies\microsoft\shared tools\graphics filters\
  • software\policies\microsoft\windows\currentversion\explorer\
  • software\policies\microsoft\softwareprotectionplatform\
  • software\policies\microsoft\officesoftwareprotectionplatform\
  • software\policies\microsoft\windows\windows search\preferences\
  • software\policies\microsoft\exchange\
  • software\microsoft\shared tools\proofing tools\
  • software\microsoft\shared tools\graphics filters\
  • software\microsoft\windows\windows search\preferences\
  • software\microsoft\exchange\
  • software\policies\microsoft\vba\security\
  • software\microsoft\onedrive

You can also choose to use existing ADMX group policies that are available for software packages such as Google Chrome and Microsoft Office. I have used both. Just be sure to encode the policy before applying them.

Here is an example of a custom ADMX policy that I created in order to apply the following registry setting:

HKCU:\Control Panel\International\User Profile

HttpAcceptLanguageOptOut

This is the Custom ADMX Policy that must be pushed to your device first before applying the actual policy setting:

Note carefully that I didn’t both to edit anything that wasn’t 100% necessary. Most of you will probably want to pretty up the category and policy names so that it is prettier. I am more of a minimalist 🙂 or maybe just a little bit lazy!

The only thing that is really important is that you:

  1. Specify which registry location and key you need to set
  2. Specify whether it is a “User” policy or a “Machine” policy
  3. Make note of the Policy Name that you are going to need to reference when applying the policy

Now that I have my policy applied, I want to set the registry key value to “1” (aka enabled). The next step is to push the following policy to the device to actual add the registry key with the correct value:

If you navigate to the registry of the device, you will see the custom ADMX Policy in this location:

HKLM:\Software\Microsoft\PolicyManager\ADMXDefault

You will also see the applied policy, in this location:

HKLM:\Software\Microsoft\PolicyManager\Current

and, of course, the destination registry key that we intended to set is now successfully applied.

Here is a really good article with video about how Custom Policies are created and applied –> https://docs.microsoft.com/en-us/windows/client-management/mdm/win32-and-centennial-app-policy-configuration

I used the article to figure out how to do this the first time, but it was a pain so I hope that my example will be helpful to you if you are looking to create a custom policy for the first time.

Using CDATA within an MDM Policy

There is a lot written on MDM policy including references to using CDATA. Here is a real life example of a policy ( InternetExplorer\AllowAddons ) written with CDATA vs. encoded:

CDATA

ENCODED

CDATA is much easier to read so if your MDM supports it, obviously you would want to use it. My personal experience is the VMWare Workspace One supports CDATA.

Please comment if the MDM that you use, supports CDATA also!

Create a Local Administrator Account

It is common to use a local Administrator account to provide Administrative access for technicians when they are imaging or configuring PCs. It would be bad form, security-wise to leave this type of account in place so it is typically deleted at the end of the build process.

If you ever find yourself in a situation where you need to re-add a local account, you can do it with OMA-DM using Accounts CSP with the following Custom XML:

Note – only Add is available with this CSP so your MDM provider will need to provide scripting support in order to provide full account management features.