Working with SSL TLS certificates is becoming more and more a necessary skill for an IT professional. We should be working towards securing most if not all traffic. The bad guys are not trying to get in, they’re probablyalreadyin (assume breach). Hopefully you have good practices in place for protecting your private keys and for renewing your certificates. Speaking of which, how do you know when it’s time to renew your certificate? Hopefully your certificate provider sends you an email when it’s getting time to renew. However you may have installed a certificate on two or more servers or devices. You need a mechanism to find the expiring certificates in your environment. This week I updated the Certificate Health PowerShell module to add the ability to check certificates on remote Windows computers as well as creating an exclusion list. You can also use the Certificate Health PowerShell module to check your key size and algorithm (sha1 is no longer safe).
You can get the latest version of the module from TechNet or install straight from PowerShell.
This year I embarked upon a journey into the world of the cloud, specifically Microsoft’s IaaS offering in their Azure public cloud. I’ve learned a lot, and I have oh so much more to learn. Over the next few posts I want to share the highlights and pain points that may help the next person.
Currently there are three types of cloud service models, but instead of using lots of words, I’ll just “borrow” an image from @NTFAQGuy that should clear things up.
I was assigned to architect a completely separate infrastructure for a business unit. They required their own application, database, and infrastructure servers as well as messaging. So I set out to research the possibility of using Azure IaaS in combination with Office 365 as a solution.
Getting started with Azure IaaS has been quite a challenge. There are so many facets to Azure that it is difficult to even define it. Furthermore its features, services, and even the limitations are constantly evolving. Typically you would want to dip your toe in the water with Azure by setting up a small proof-of-concept environment. It could be as simple as signing up for an account, deploying a few VM’s, and establish a site-to-site (S2S) VPN back to your on-premise network. Of course everything that seems simple in life tends to be a lot more complicated once you start to dig a little deeper.
For starters the process of signing up for an account seems dead simple. You go to the Azure website, give them a credit card, and you’re in. However if you’re signing up for Azure for your company there are additional questions that need to be answered. Who manages the subscription(s)? Is your subscription part of your existing Enterprise Agreement? How do you configure the Azure pieces so that the proper services are billed to the correct departments? How do you give access and reporting to the accounting department for the Azure subscription(s)?
Fortunately you don’t have to answer all of these questions right away, but you should be asking them. Remember that all things temporary in IT usually end up being permanent so take care how you get started.
The Nugget of Wisdom
Pay special attention to which account that initially signs up for the Azure account. That email account will be the subscription owner. Don’t use a person who may one day leave the company (like yourself). Setup a mailbox or distribution list that will function as the main account.
Next time we’ll dig deeper into the IaaS offerings including dealing with ASM vs. ARM and what does that even mean.
Hello. My name is [redacted], and I’m a performance junkie. It’s been five days since I wrote a PowerShell script to make me work faster.
Sometimes I feel like a NASCAR pit crew chief constantly trying to find ways to shave off seconds of inefficiencies in the way that I work. I’ve learned that the less I leave the keyboard to use the mouse the more I can get done, especially if I just need to start an app.
The Start Menu was introduced to the world with Windows 95 and has gone through many iterations since. Since Windows Vista, Microsoft built search into the Start Menu to help us “quickly” find the apps we wanted to use. Unfortunately it hasn’t been very fast, perhaps because the search is also accessing an index of files and email as well. In 2007 Launchy was created to be a single purpose application launcher to quickly start apps based upon keystrokes. Once I taught myself to use it, I have never looked back. I still use the Start Menu for various purposes, but to start my apps I just press Alt + Space, type a few letters and press Enter.
With Windows 8/8.1 and Windows 10 Microsoft is moving to a new style of app which has gone by many names, Metro, Modern, Windows Store, and now Universal Windows Platform (UWP). These apps are packaged into a Appx format and run in isolated ‘containers’. These UWP apps are registered into the modern Start Menu, but not as shortcut files which means Launchy can’t index them. I set out on a journey to figure out a way to get Launchy to “see” these apps so that I can keep my hands on the keyboard.
My first thought was to find the exe that associated with the UWP app. UWP apps are installed in two locations.
Paths to UWP Apps
However running those exe’s didn’t seem to do anything, or it popped up the SmartScreen warning.
I did find the processes suspended in the task manager.
It seems like these exe’s have to be launched via the container or host process. I hit a dead end, or it was time for another approach.
I found some information on the Googles (actually Duckduckgo) on UWP apps registering protocols which can be used to launch the app. Now we were on to something. The blogs and documentation I found listed example apps and their protocols, but not how to retrieve them. I decided to look into the PowerShell Appx module.
Cmdlets for Appx Module
CommandType Name Version Source
I started with Get-AppxPackage to see what properties the cmdlet would output. The only properties I found that were useful were Name and InstallLocation.
From there I browsed the xml tree until I could find and isolate the protocol. Now that I had a found a way to get the protocol for UWP apps, I had to look up some code for creating shortcuts from PowerShell using the COMObject.
Instead of making one “big” script to do the whole process I decided to make one script per tool. One script’s job was to “get” the protocol of an UWP app and then another script to create the shortcuts.