Upgrading from 3.2 to 4.0 has some special steps to get you upgraded. Due to the large infrastructure changes, and new features in 4.0, a simple upgrade, migrating settings just isn’t possible.
Items that don’t migrate: permissions/roles, lab manager profile (now renamed Kiosk manager), and Builder actions. In order to help recreate them in 4.0, we recommend you document the permissions and export the lab/kiosk and Builder items before the upgrade. Then load them into a 3.2 standalone enterprise install afterwards, so you can reference them when you recreate them on 4.0.
Good news, future releases will be the simple upgrade. Before going much further, the official docs for the Installation of 4.0 are here, along with detailed info.
Lets do a quick reminder of the backend differences:
Starting the Upgrade, if running on the same server, you’ll notice right off the bat additional Pre-Reqs are needed to support 4.0. Pre-Reqs: Recast Server requires a domain joined Windows Server 2008 R2 or later server for installation with IIS enabled, the .NET Core Hosting Bundle needs to be installed, and a SQL Server Express (or better) server needs to be available. If the .NET Core Hosting Bundle was installed before IIS was installed, you will need to repair the .NET Core Hosting Bundle installation.
Domain Joined Windows Server Standard, testing has been done up to version 2019.
On my Recast 3.2 Server, before starting the upgrade, I already installed SQL Server 2017 Express LocalDB and SQL Server Management Studio [OPTIONAL] to manage the Database. I also installed the IIS Feature. [which was already installed because this server doubles as a ConfigMgr Management Point]
Now I’ll install the other Pre-Reqs, clicking the Link brings up the website, launching the installer, then checking the box and clicking “Install”
Now that .Net Core is installed, re-launch the Installer, and follow the Prompts
Make sure the “Test SQL Connection” returns “Success”
After installing, you can see 3.2 is no longer installed. The 4.0 Installer removed 3.2.
After the Install is finished, it will prompt for Reboot, which is highly recommend. If you don’t and you launch the web console, you’ll find yourself quite annoyed at the behavior of being prompted over and over again for creds. Just reboot and save yourself a little frustration. Once rebooted, go ahead and launch the Browser Based Console (From any machine that can connect to port 444 on the Recast Management Server)
In Recast Enterprise Right Click Tools, if you’re familiar with 3.2, and you’re looking through 4.0, you will notice that Lab Manager is no longer there. Fear not, the feature sets you’ve come to rely on are still in 4.0, but separated out in to two feature subsets: Kiosk Manager & Unified Write Filter. We’ll focus on Kiosk Manager in this post.
Kiosk Manager is a way to apply several settings to a machine or group of machines to lock it down, or turn it into a single use machine… like a kiosk, for example. 🙂
First, create a Profile using “Manage Profile”
For this example, lets display all of the options.
Now that we have a Template, lets apply it to a machine and see what happens. Right click on the machine, and go to “Apply Profile”
So we apply the Library Profile, Deploy it Immediately, it will reboot the machines to apply, which is also a good reason to schedule it.
After the reboot, the machine performs the auto-logon with the account information provided, it then launches the replacement shell, in this case, Chrome.
So, it had some of the desired effects, but since we’re using the whitelist, it only shows the content of the items added to that list, apparently many of the graphics are hosted under a different domain name. Open “Developer Mode” in Chrome, and grab the other URLs that are needed, and an update to the WhiteList Tab in the Template.
After you make a change to the template, you have to RE-Apply it.
Now the machine will apply the updated template, reboot, and have your changes applied.
There we go, that looks better. Auto Logon to Chrome Browser with the Default Website set to RecastSoftware.com and the user is blocked from making modifications. If the Kiosk is left unattended for 30 minutes, it reboots to a fresh state.
To get the most out of Kiosk Manager, leverage GPO to set lock screen settings, power options, and other control features.
Recast Software recently released Right Click Tools 4.0. Updates include minor enhancements to the Community edition and an entire infrastructure overhaul to the Enterprise edition. Here’s a quick overview on what’s new:
Recast Proxy, adds Multi-Domain / Workgroup Support
Kiosk: Manage Kiosk devices quickly via custom templates you can create inside the tool. [Blog Post]
Unified Write Filters: Lock down a machine, controlling which areas of the drive are write-able, and which ones revert each reboot.
Builder: Used for automate repetitious console actions. [Blog Post]
System Information Update
Adds Windows 10 Build info
Adds Battery Info Tab
Dashboards: Quick view of your environment’s status for Software Updates, LAPS & Bitlocker.
Export to CSV, allows you to easily capture the data for further manipulation and reporting.
Deep dive blog posts will be coming for each of those new features soon, so stay tuned!
What does this mean for Community edition users? It means that the powerful tool set continues to evolve with each release. As for the Enterprise customers, there was a lot of movement under the hood in this release. Nearly a complete re-write of the code base to help align future development with an agile work flow, allowing a more rapid release cadence. Along with architecture improvements, you’ll see drastic changes in Builder. If you used it before, you’ll really appreciate the update to this automation engine.
Expect upcoming blog posts to cover these updates in further detail and examples of how to leverage them.
In the meantime, download Right Click Tools 4.0 today and test drive the new features (receive 30 days of Enterprise free when you download the tools).
Good hook of a title right? Here’s why I say that, LAPS (Local Admin Password Solution) has been around for several years, and I’d be willing to bet, a lot of orgs haven’t implemented it yet (total guess here, no actual data, other than my twitter survey shown below). Good news, many have, as I had at a previous employer. It’s simple to setup, and greatly reduces a previously easily exploitable attach vector. LAPS … mitigates the risk of lateral escalation that results when customers use the same administrative local account and password combination on their computers . -Microsoft
So there you have it, you have it setup, if not, see previous post, now you move on with your operational duties and focus on what fire your manager throws at you today. Why is that? Who seriously did client health for LAPS once it was setup? Who confirmed it was working on all end points? I certainly didn’t, I had “bigger fish to fry”. But as with any implementation, you need to check up on it from time to time. This shouldn’t be a surprise, you do this with the ConfigMgr Client, you monitor Client health, perhaps even implemented auto remediation scripts. You probably monitor your AV / Anti-Malware system, IDS, Disk Encryption, etc. So why not LAPS?
So the team at Recast Software created a nifty dashboard for you to monitor your LAPS “health”. This is included in the Enterprise version of the Right Click Tools. Here is an image from their Documentation, has a bit more date than my little lab:
Why I like this is because I’m already in the CM Console every day, to have a dashboard for LAPS, to keep it visible and at the front of our minds, I find this highly useful. It only takes a few seconds, pull it up, check my stats, and move on. If I find an anomaly, I can start looking into it.
What else do I like? Glad you asked, I like that I can look up the passwords here. No need to make a special package for my Service Desk Techs to be able to lookup passwords, they already have the CM Console, now I just grant them permissions to this feature and they now have a powerful tool for when they need to look up these passwords for their support needs.
Is that all? Nope, I like that I can export this list to CSV file, and provide it to the Security Team / Audit Folks, who want to confirm compliance.
Currently in version 4.0, this dashboard is querying AD to see which computers have a LAPS password. In 4.1, additional features are planned to be incorporated into this dashboard, which will require additional permissions, but I’ll cover that once it’s released.
So how do you set this up? I’ve got the Right Click Tools Enterprise license and setup the Recast Management Server, what are the permissions I need to allow my Service Desk to view this dashboard? What permissions are required to allow my Service Desk the ability to view the passwords? I’m going to go over that, building off of my last post where I setup LAPS and created AD Groups with different permissions for LAPS. Assumptions before continuing: You have Specific AD Groups you want to grant permissions to.
First, in my Lab, I have my Service Desk Tier 1 -3 Support positions have different access to the CM Console. I want all of them to have the ability to see the Dashboards and pull up the passwords. In CM:
Before I add any permissions, this is what the Dashboard would look like without the proper permissions: (Using Service Desk Tier 1 User)
So now we know what it looks like when you don’t have rights, lets add some permissions. In Recast Management Server, I’ve created a ReLAPS role with just permissions for the ReLAPS console. Testing with 3 “Rights” from the options.. getting close…
Ok, this looks better: (Still using a Service Desk Tier 1 User)
So what does this look like in the Recast Management Server Console?
Created a ReLAPS Role with minimum requirements for ReLAPS console.
Then added the LAPS Read Only Group, and assigned it to the ReLAPS Role:
Ok, now you can rest easy knowing your Service Desk has the ability to do the only tasks you want them to do, and no more. Sure, you probably already granted them far more rights to use other tools already, but hey, if you find you have a need to only allow users to view that Dashboard, you will now know how.
In a future post, once Right Click Tools 4.1 is released, I’ll be creating an updated post with the additional permissions required. I’m also thinking about going into scoping LAPS, ie allowing Server Admins to only see Server LAPS passwords and Service Desk to only see Workstation LAPS passwords. Let me know if this is something of interest.
“The “Local Administrator Password Solution” (LAPS) provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset.” – Microsoft. Basically, it reduces the risk of having a default (backdoor perhaps) local administrator & default password on your machines by having each machine use a different complex password for the account. Before LAPS, most organizations had a generic local admin ex: ORG_LocalAdmin, with the same password on each machine ex: ORG_P@ssword. Problem with that is, if a machine was compromised, the malware / hacker could move laterally among all your machines gathering more and more data to deepen the security breach. With LAPS implemented, you remove that attach vector, if one machine is compromised, the ability to move laterally to another machine is greatly reduced.
There are quite a few guides out there, and the Microsoft Docs are pretty good too. I didn’t do extensive searching before creating this post, so note that this may be redundant.
In this Walk-Through, I’ll cover
Create Source Folders
Create End Point Installer Application
Deploy LAPS Application to End Points
Extend AD Schema (From Domain Controller)
Setup LAPS AD Groups and Permissions
Manually Install LAPS Admin Client
Verify Permissions and Read / Reset Access
Basic Enable of Group Policy
Tests to confirm Permissions are working
Things I’m not covering
The Why’s behind each step. Much of the details and reasons why you have to perform these steps are already documented well in the Microsoft “LAPS_OperationGuide” which is part of the download, and quite honestly, that’s what I’m using as I create this Walk Through, so I suggest you look over that before you even start.
Every Deployment Scenario. This is a generic and SIMPLE Lab, while much of this is the same for any environment, each environment is different, each organization is setup differently. LAPS setup will probably require multiple teams involvement (AD / CM / Deployments / GPO)
Things to Consider beforehand
Active Directory Structure (OUs with Workstations)
I’ve downloaded all of the Files into a “LAPS” directory then created a new folder to move the MSI Files into.
In the CM Console, Create a new Application. Point it to the x64 version of the MSI
Once you choose the MSI can Next, it will pull the information for the Application from the MSI
As you click Next, you’ll come to General Information, I added “Microsoft” as publisher, and changed /q to /qn
At this point, just click Next, leaving the defaults until it completes and you click Close. You’ll now have the Local Administrator Password Solution application in your console. We just need to make a couple tweaks. In the Properties of the application, click on Deployment Types Tab, choose the Deployment and click Edit, go into Requirements an add the x64 for versions of Windows in your Environment.
At this point, we have the App, lets get it deployed to the workstations. Since you’ve added the logic into the app, you can safely deploy it to your all workstations. NOTE, this is when knowing your environment, you deploy to the appropriate collection. Perhaps you have a business reason to not deploy it to all workstations. Just use best practices for deployments (Maintenance windows, etc). Rest of this example is just generic.
I left Scheduling set to defaults, User Experience , Alerts all defaults
Admin Client / LAPS Management Client
So now that the Client is being deployed, lets get the infrastructure setup. First we’ll switch over to a client test machines / or your typical admin workstation. Lets get the LAPS Client Installed along with the Management Tools. Once you kick off the installer (Double click the MSI), click through the first couple screens to get to the “Custom Setup”, once here Enable all options.
Go ahead and let it install. We’ll need to grab some of the items it installed and we’ll copy them back out to our source server for easy access.
Go to C:\Windows\PolicyDefinitions, here you will grab the AdmPwd.admx file, and the AdmPwd.adml file from the en-US subfolder. I created a folder called GPO_ADMX in my source location to copy them to.
Also, Copy the AdmPwd.PS folder from the PowerShell Modules: C:\Windows\System32\WindowsPowerShell\v1.0\Modules
You’ll need those later.
Now, these steps you can do from your workstation (and should), but to make sure I had connection and rights, I did it from my actual Domain Controller. You’d typically do this from an admin machine with proper credentials, as your DC’s should be CORE and not even have a desktop experience. You typically never want to actually log onto a DC. But this is lab, and I’m just making a demo.
Modify the AD Schema
On the Domain Controller, copy the AdmPwd.PS folder you uploaded to your source into the local module repository on your DC, then launch Admin PowerShell Console. In this image, you can see I tried to Import-Module before I had copied the files onto the DC, after the copy, the command runs correctly:
Run the command: Update-AdmPwdADSchema:
In my lab, you can see it successfully added 2 attributes and modified one class.
Hopefully you considered a few things before starting this Journey, like which OU the workstations are in that you want to apply this to, and who do you want to have permissions? For my lab, it’s pretty easy, I have 1 Master OU setup for WorkStations, and all other workstations fall into Sub OUs of that Master OU.
At this point, it’s nice to check and see who has rights to view that info in AD. In your PowerShell console, type “Find-AdmPwdExtendedrights -identity <OU Name> | Format-Table
As you can see, rights are pretty clean, I’m ok with those folks having rights to LAPS.
Now, in AD, lets setup a Read & Reset Group, to grant access to LAPS. I’ve created two groups: LAPS Read Only & LAPS Reset PWD:
Now we need to grant Machines the ability to update it’s own password, we we grant access to the “SELF built-in account” for all machines in the Workstation OU: Set-AdmPwdComputerSelfPermission -OrgUnit <OU Name>
Next we need to grant users rights to look up that information, this is where those groups come in. We’re going to give “LAPS Read Only” rights to Read LAPS Passwords: Set-AdmPwdReadPasswordPermission -OrgUnit <OU Name> -AllowedPrincipals <FQDN Group Name>
We’re going to give “LAPS Reset PWD” rights to Reset LAPS Passwords: Set-AdmPwdReadPasswordPermission -OrgUnit <OU Name> -AllowedPrincipals <FQDN Group Name>
We’re also going to confirm it did something using the Find.. command:
Now, in AD, you can nest the groups you want in your LAPS Security Groups to have access:
For my Lab, I have Service Desk Tier 1 & 2 Read only, and Tier 3 can Reset.
Group Policy You’ll need to copy the ADMX & ADML files you copied to your source folder into your Group Policy Central Store, which can be located here: \\FQDN\SYSVOL\FQDN\policies
Now you can Launch Group Policy and create your LAPS Policy. For this Demo, I’m going to create a new simple Policy, but you can always add it into one you already have. The new GPO is set to defaults, except I disable User Policies, as this will all be machine based, no point in having it look for user policies:
I’ve setup the basic settings to make this work with my lab. In my lab, I have a local admin account on the computer besides the disabled default, which is named “MyLocalAdmin”, which is the account I want LAPS to manage:
OK, that’s it, you have it all setup. Now it’s time to confirm you get the results you wanted
Standard End Users (Should have No Rights)
Service Desk Tier 1 (Should have Read Access)
Service Desk Tier 3 (Should have Read / Reset Access)
Test 1: Standard User:
Test 2: Tier 1 Service Desk:
Test 3: Tier 3 Service Desk:
We learn from this test, Reset Permissions does not include Read. So, unless you have a need for a group to be able to reset this password, and not read it, I’d nest the LAPS Reset PWD group inside of the LAPS Read Only Group
Now we have the desired results, Tier 3 Support can both Read & Reset the LAPS password.
I hope you found this LAPS overview useful, and hopefully provided additional information not found in other ones. The main reason I’ve writing this, is for Part 2, configuring Recast Management Server User / Groups to view ReLAPS (LAPS) Dashboard in the CM Console. Stay Tuned!
Hey Recast Right Click Tools users. This is a nifty tip that I often forget about, but is pretty powerful when adding or removing machines to and from collections. Bonus.. learn about Direct Membership vs Evaluated Membership.
Blog Summary: Wild Cards!
Lets say I want to add all machines that start with “town” into a collections… wild cards make this simple.
In this Demo, I highlighted 2 collections at the same time, and launch the tool “Add Computers to Collection(s)”
I’ve added my wildcard name, %town%, lets see what happens:
You can see here, it has added the machines with the string ‘town’ in the name into the collections.
Something also to note, in my demo I have one collection limited to “All System” (FYI not a good practice) and one collection limited to 1607 machines collection. After I’ve added the devices, you can see the collection counts are different, as only 1 machine in the batch is in the 1607 collection (the limiting collection). If I show the evaluated results of that collection, there would only be 1 device, as opposed to the direct membership there would be 14, the same as the collection without a limiting collection.
Now, lets say you want to remove machines that have the word “pc” or “hp” in the name, and leave the rest…
Pretty simple. After the removals, there are only 3 devices in each collection (Direct Membership), and the one with a limiting collection now evaluates to 0 machines, because none of the machines in that collection are part of the 1607 Collection.
I hope this demo shows the power of the Add / Remove Computers Right Click Tools, along with the difference between Direct Collection Membership and Evaluated Collection Membership.
Configuration Manager creates a lot of data. We can be better systems managers if we can use that data to make decisions, but that process is not always as simple as it sounds. Often, getting at the data you need in the console feels like traversing a crevasse. You can see where you want to go, you have a good idea of how you might get there, but when it comes to actually getting across the gap there’s a lot more to it than first meets the eye.
This problem often leads to something I like to call data paralysis. In the same way you might look down with trepidation over the edge of that gap or break out in a cold sweat at the broken rung, surfacing the data you need to make systems management decisions has a lot of ways you can get sidetracked. We take one look at the gap we need to cross to get make the decision we need, and spend days trying to find a way to fix or fill it– spending a lot of time and effort but going nowhere.
Build a Better Bridge
The solution to many of the procedure issues that cause gaps in the decision making cycle is to build a better bridge. This is one of the main reasons we created the Right Click Tools in the first place– when we can surface data more easily, refine that data to a usable state, and then act on it immediately, we avoid data paralysis altogether.
The RCT Enterprise Query tool is a perfect example of this:
If you would like to see more of how the Query tool and other Right Click Tools can help you improve your data-driven decision making– schedule a walkthrough with us. It’s a quick, low pressure way to learn more about the tools, ask technical questions, and see how the tools can help in your environment.