Last updated on April 3rd, 2024 at 06:13 pm
I had this unbelievable idea of moving ConfigMgr Health Services in the Cloud instead of having it on-prem. This is just phase one of a long list of things I’m trying to work out with the ConfigMgr Health script.
Now when I say in the cloud, I don’t mean Azure or AWS. I mean inexpensive web hosting. My current provider has plans as little as $2.95/month USD. I’m using a more expensive plan because I host many different sites. Anyways one of the problems that many companies have with cloud services is cost. Particularly with uncertain cost. Using an inexpensive or fixed cost service, is something many companies are in favor of.
Let’s be honest, I wasn’t sure that putting Anders Rødland ConfigMgr Health API on an inexpensive web hosting site would work or not. I need to test it myself. And I did. Using one of the domains that is Co-hosted on the same service as Ask Garth website on. I was able to get this service to work.
So why host ConfigMgr Health Services in the Cloud?
This is a great question; the short answer is CMG (Cloud Management Gateway) and future projects. The long answer is, you will see many blogs on the subject of expanding the ConfigMgr Health script to add more to it so that it will work perfectly where on not the device is on-prem or being used in a work from home situation.
ConfigMgr Health Services in the Cloud
So how do you do it? It turns out this is simple. I just followed the instructions that I followed within Configmgr Client Health – Anders Rødland Startup Script. Make sure that you check out the video below.
For this project I will use one of my test domains.
Cloud Providers
Since there are many web hosting companies out there, I can’t possibly show you for all of them the steps need to create ConfigMgr Health Services in the Cloud. Instead, I will show you from my provider. This should give you a good idea as to what you will need to do with your own provider.
Security
This will be an interesting question and answer. Clearly for my lab, in my option, the data that is return from the health script to API is not in any way sensitive data. There is nothing a simple hacker can’t get already quickly with off the shelf tools. But at the same time, I can see many security teams not be happy.
But is the risk any higher than if you hosted this API in your own DMZ? I would suggest not and is arguably more secure. Why is it more secure? Well, most providers will have a sec team themselves and will be watching for brute force attacks and a like. Although internal IT sec teams will be doing the same. The provider IMO will act faster than internal teams. All of this is to say that you need to evaluate What is the risk if all of the data is obtained by hackers. I can’t answer this for you.
Hosting
There are things that you can to mitigate the risk. For example, I would not host the startup script on this site, only the API endpoint and database. Next almost every hosting company will provide a few SSL certificate via Let’s Encrypt. Make sure that you use the cert and ensure that it is updated. Your provider will likely have a security team which will keep an eye out to brute force, other security attacks and thing of that nature. I’m sure they will let you know if your site is causing them a problem.
Database
You can ask your provider if they encrypted the data at rest, some might. You can additionally look at encrypting the data itself. Also ensure that any account that you are using has a ridiculous password. And only has minimal access.
Start-up script itself
You can code sign the script (How to Code Sign PowerShell). You can ensure that you are not host the script anywhere that you don’t fully control. Or better yet re-code it as an EXE in C# and code sign that EXE.
ConfigMgr Health Services in the Cloud Video
In this video, I show the steps that I took to put the Client Health script in the cloud.
If you have any questions about ConfigMgr Health Services in the Cloud. Please feel free to contact me @GarthMJ Please also subscribe to my YouTube channel and newsletter.