Windows makes it incredibly easy to run an application or script as another user on your computer. I find that I most often use this to run administrative or domain tools, when I’m logged in as just a normal user.
Method 1
This is the easiest method. While it took me a little while to remember it, I now use it almost daily and without even thinking about it.
Press and hold down the ‘Shift’ key on your keyboard, while you right-click on the program you want to launch.
This will only work on executable (EXE) files or shortcuts to executable files. If you try this and don’t see the option, then it is not an executable file.
Method 2
This method will create a shortcut that “knows” to launch an application as another user.
Create a shortcut to your executable
Right-click on the shortcut and modify the “Target” to:
runas /user:DOMAIN\USERNAME "path to executable"
Click ‘OK’. Then launch your shortcut. You will get prompted for your password everytime you launch your shortcut.
If you need to store the password with your shortcut, then modify the “Target” to this instead:
runas /savecred /user:DOMAIN\USERNAME "path to executable"
Click ‘OK’. Then right-click and select “Run as Administrator” the first time you use the shortcut. You will be prompted for the user password and it will get saved. From then on, just clicking the shortcut will launch it as your desired user.
Method 2.5
Alright this is basically the same method as above, so I didn’t feel right calling it a third method.
You can take the same trick from “Method 2” and just use it to run an application from a command prompt window.
C:\> runas /user:DOMAIN\USERNAME "path to executable"
Using GPOs is a great way to allow or block programs from running on your corporate network. Just be careful and limit yourself to only blocking the applications which you actually have a need to block. Don’t go too crazy locking down programs
Microsoft first made the introduction of “Software Restriction Policies” in Windows Server 2008 and they’ve continued to evolve. Today I will show you four ways which Microsoft allows us to restrict programs from running.
File Path / File Name Rule
Network Zone Rule
Hash Rule
Certificate Rule
To begin, fire up the Group Policy Management Editor. Click on the start menu and type “gpmc.msc”. If you are on a Domain Controller it should work. If you’re on a workstation you’ll likely have to run Server Manager as a Domain Admin (or other user with the correct administrative privileges), choose “Group Policy Management” from the ‘Tools’ dropdown.
Once it’s open, scroll down to the folder “Group Policy Objects” and right-click on it to create a “New ” policy object. Give it an appropriate name, something like “Software Restrictions – Test”. Now find and right-click on your new policy and select “Edit…”.
The software restriction policy exists under both “Computer Configuration” and “User Configuration”. So depending on your needs, you can lock down either the user or the computer.
Drill down into the policy… “Policies” -> “Windows Settings” -> “Security Settings” -> “Software Restriction Policies”.
Right-click on “Software Restriction Policies” and click “New Software Restriction Policies”
Select and open the “Additional Rules” folder.
Right-click under the two pre-existing default entries, and then from that drop-down menu select the type of rule you want to create. I’ll expand on the four methods below…
There are three security levels used in all of these rules:
DISALLOWED: Software will not run, regardless of the access rights of the user.
BASIC USER: Allows programs to run only as standard user. Removes the ability to “Run as Administrator”.
UNRESTRICTED: No changes made by this policy – Software access rights are determined by the file access rights of the user.
My examples below all show how to block software with ‘dissallowed’ rules. But just remember that you can just as easily allow for software by using ‘basic user’ and ‘unrestricted’ rules. Use them wisely!
1. Block by File Path / File Name Rule
In this example I will show you how to lock down the computer from running WordPad.
Select “New Path Rule”.
Type, or use the “Browse…” button, to enter the file path or file name you wish to block. Make sure that the ‘Security level’ is set to “Dissallow”. Then click ‘OK’.
Note: System variables will all function in the rule, variables such as %windir%, %ProgramFiles(x86)%, %AppData%, %userprofile%, and others.
It is important to note that many applications launch in more than just one way. So you may have to block multiple executables to fully block the application, just fyi.
You also need to take note of where/how software get launched from, as some applications have multiple ways they can be launched. Just FYI, in case you start banging your head as to why some block rule doesn’t seem to be working.
Also be careful using just the file name itself to try to block a program from running. If you were to block just the file name ‘update.exe’ for example, hundreds of applications all ship with an ‘update’ executable and they would all be hindered and unable run.
My rule of thumb is to always use the full path unless it’s truly a unique file name, and even then I still prefer to use the full path.
2. Block by Network Zone Rule
Select “New Network Rule”.
Select the Network zone you want to block. Make sure that the ‘Security level’ is set to “Dissallow”. Then click ‘OK’.
These rules allow you to block programs if they come from sites you’ve designated into a zone, like your Restricted sites. Or in the case that you were to be creating an allow rule, your local Intranet. While this option exists, it seems unlikely to me that most SMBs ever use it.
3. Block by Hash Rule
In this example I will show you how to lock down the computer from running WordPad.
Select “New Hash Rule”.
Use the “Browse…” button to navigate to the file which you are wanting to block. Select the file and click ‘Open’. It will automatically pull the needed file information and the “hash” it needs from the file you selected. Make sure that the ‘Security level’ is set to “Dissallow”. Then click ‘OK’.
The only problem this method has is that file hashes change any time there is ANY change to file. It doesn’t matter how small of a change is made, it will always create a new hash. That means that hash rules are best applied to older software that you are trying to kill, and not for programs that get updated often.
4. Block by Certificate Rule
In this example we will be blocking applications signed by Adobe Inc.
Select “New Certificate Rule”.
Use the “Browse…” button to navigate to the certificate file which you are wanting to use to block signed software. Select the file and click ‘Open’. Make sure that the ‘Security level’ is set to “Dissallow”. Then click ‘OK’.
Certificate rules are by far one of the most secure rules as they rely on certificates from trusted publishers. Because of this but they require more work on the PC’s part as it goes out and tries to verify the validity of the certificate, so they may significantly effect performance. I can’t tell you how much of an impact they’ll create, but it’s enough that MS warns us. Also, if the certificate ever expires, you’ll need create a new rule.
The Quick Access links is a feature in Windows that gives the user an easy way to access the folders which use frequently by pinning them to the top of the left pane in ‘File Explorer’. Sometimes the file that stores the pinned items can get corrupted and thus you loose access to the Quick Access pinned items. Here’s a few ways to fix it.
Method 1
We can reset the Quick Access Recent Items. This method will only apply to “stuck” recent folders, and won’t affect your pinned folders.
Right click on the Quick Access star icon and then click on ‘Options’.
Click the ‘Clear’ button under ‘Privacy’.
All of your Recent folders will be cleared from the Quick Access list.
Method 2
This method will reset and clear the Quick access shortcuts. But in my opinion this is the better way to fix it, as you can always re-pin your shortcuts.
Open File Explorer and copy/paste the following folder location:
Look for and then delete this file from the folder:
cmd.exe /c del “%AppData%\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms”
*Or you can open a ‘Run’ dialog (Windows key + R) and copy/paste the following command into it to delete the file.
cmd.exe /c del "%AppData%\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms"
This method will remove and clear any custom pinned items and frequent items from the Quick Access list. Windows will automatically regenerate the “f01b4d95cf55d32a.automaticDestinations-ms” file the next time that you launch File Explorer and wil list the default Quick Access links which you can expand upon.
A bad user profile could happen to any one of your users. It could happen in Windows desktop or on a server. The user will log in and instead of their profile getting loaded, the OS decides it wants to load a temporary profile the the user. The user will a pop up message stating “You have been logged on with a Temporary Profile” and that any changes won’t get saved.
It can be frustrating for the user, for sure. However, once you know where to go to fix it, it’s not too big of a deal.
Why does it happen? Well there are a variety of reasons. It could be corrupt. It could be delayed, likely from an antivirus program, or some service not responding, or many other operations. Once Windows has loaded a temporary profile for a user, it will continue to do so. That user will always load their temporary profile until you fix it.
How to fix it? You can try to reboot the computer. Depending on whether this is a desktop or server, that may or may not be an easy task to try. If that doesn’t resolve the issue, follow my steps below to fix it. It should work in almost all cases.
1. Login as an ‘Administrator’ to the machine.
2. Click the start button
3. Type “reedit” and then right-click on program to ‘Run as Administrator’. Click ‘Yes’ to any UAC pop up.
5. You will see a list of all of the profile names. Two will be named the same, with one of them ending with “.bak”.
The temporary profile does not have the ‘.bak’ at the end of it. The original or “old” profile has the ‘.bak’ at the end of it.
6. Now that we know which profile is which, we need to rename them.
We need to rename the temporary profile by adding a ‘tmp’ to the end of it.
Next we will rename the original profile by removing the ‘.bak’ from the end of it.
7. Reboot the computer to complete the process.
8. Log back in as the affected user and it should now load the original profile.
9. Once the original profile has been restored, as an administrator you can re-open the regedit tool and navigate back to the same entry from “Step 4”. Right-click on the temporary profile that ends in ‘.tmp’ and select “Delete” to permanently remove it.
If the did not help, then your only other option would be to create a new user profile. To do this, you’d need to, as an administrator, delete the user profile before having the user log back onto the machine. Everything such as user documents and files would be lost though. Hopefully you have a good backup of your data that you restore from.
The Folding@Home (F@H) team has released v7 (currently v7.5.1) of their F@H software. It has a newer simpler graphical interface aimed at making it easier for people to install and contribute to the project. Here is how to make it run on your Windows computer.
2. Double-click the file to start the installation. If an UAC prompt is displayed, click ‘Yes’ to continue.
3. Click ‘Next’ on the Welcome screen to continue.
4. Read and accept the license agreement by clicking ‘I Agree’.
5. You have two options, do the ‘Express install’ or the ‘Custom install’. I am going to click the ‘Custom install’ to be able to have a bit more control over the installation.
6. Choose the install folder destination. I’m leaving it as the default.
7. Choose the folder for your data. Again, I’m leaving it as the default.
8. You have three choices as to when you want F@H to start; (1) At login, (2) As a service at boot, or (3) manually. You also have the option to enable a F@H screensaver.
9. Click ‘Finish’ to complete the installation.
Running F@H
1. If the F@H client did not launch or is already installed, click on it’s icon on your desktop or in your start menu.
2. The first time F@H runs, you will likely see a popup message from Windows Firewall, asking to grant F@H network access.
3. It will open the F@H in your broswer. Once open, click on the link to ‘Change Identity’.
4. Enter your F@H username, passkey, and team you want to be associated with.
5. After you have entered your user info, you can see your points earned and work units you have been assigned. That’s it! You are now contributing to F@H.
I know that I left my F@H username and passkey in my post. Go ahead and use my F@H username & passkey if you really want to… It just means my F@H user will get credit for any folding you do.
An important part to any OS deployment is joining the computer to the domain. The whole point of Microsoft’s Deployment Toolkit (MDT) is to automate as much of your deployment process as possible. So it is no surprise that MDT, when properly configured, can automagically join your newly deployed machine to the domain. It’s actually pretty easy to setup.
Part 1
The first part of allowing MDT to join machines to the domain is to setup a unique service account specifically for the task of joining machines to the domain.
Microsoft has helped to make things easier for us and has created a PowerShell script that can be downloaded, placed on your Domain Controller, and run to set a service account up with all of the necessary account permissions to manage computer objects in a specified OU. The script and instructions can be found under ‘Step 1’ at this link: https://docs.microsoft.com/en-us/windows/deployment/deploy-windows-mdt/deploy-a-windows-10-image-using-mdt
Part 2
The second part is going to be adding the correct values into your CustomSettings.ini file. There are the four variables that we need to add to automate the domain join, and one recommended value to skip the corresponding Domain Membership page in the Task Sequence wizard;
JoinDomain = The domain we are wanting to join.
DomainAdmin = The username of the service account we created earlier.
DomainAdminDomain = the domain that the service account resides. It’s typically going to be the same as the ‘JoinDomain’ value, but depending on how your AD Forest is configured, it is possible that it could be a different domain.
DomainAdminPassword = The password to our service account.
SkipDomainMembership = Yes/No. A ‘Yes’ value will skip the wizard page that asks about domain membership. A ‘No’ value will show the domain membership page.
Here is an example of how it would look when entered into the CustomSettings.ini file.
One additional item you may want to add to your CustomSettings.ini file is a value to specify which OU object you want the newly joined machine to be added to.
MachineObjectOU = Active Directory OU object you want machines to added to. It’s where you would have specified when creating the service account and running MS’s PowerShell script.
Which would look like this in the CustomSettings.ini file.
You’ll want to make sure the OU is properly set for your domain. However, if you prefer to not specify an OU, your machines will all end up in the default ‘Computers’ OU of your domain, no harm there, you will just need to then manually move them into their correct OU.
Here’s what all the combined values I covered in this post would look like when added to the CustomSettings.ini .
With the service account setup and the values added to our CustomSettings.ini, your deployments should now have no problems getting joined to your domain. Congratulations! You’ve streamlined one more deployment task.
Johan Arwidmark is basically a guru in the world of Windows deployment. His blog (deploymentresearch.com) is a literal treasure trove of information for all things deployment related and it is where I found this tip.
By editing your CustomSettings.ini file you can actually set the resolution values to be written to your unattend.xml file during deployment. How handy is that!?!
When using Microsoft’s MDT for deployment, sometimes you need to create a bootable USB to boot your machine into a LiteTouch deployment. Well Thanks to an application named Rufus, that could not be any simpler. Rufus is a utility that helps to format and create bootable USB flash drives, such as USB keys/pendrives, memory sticks, etc.
After creating your MDT iso, copy it onto your workstation, or whichever machine you are creating the bootable USB on.
Download and install Rufus (at the time of writing this is at v3.8). https://rufus.ie/
In Rufus;
Select your USB from the Device dropdown menu
Click on SELECT, and choose the MDT iso you copied to your workstation
If desired, modify the Volume_Label to the name of your preference
Under the File system dropdown menu, select NTFS
Click on START to begin formatting your device
Now, as long as secure boot is disabled, you can boot direct from your UEFI enabled thumb drive and get to your MDT task sequences.
Was beginning the introduction of Windows Server 2019 to a work environment and ran into some hurdles that were easily cleared, but want to share…
To begin with, you need to have a Volume Licensing agreement with Microsoft. We did and so I jumped into the MS Volume Licensing Service Center (VLSC) portal to grab our Client Specific Volume License Key (CSLVK) Key Management Service (KMS) key.
The CSLVK KMS key is what gets loaded into the KMS server. It’s basically your volume license key that gets hosted internally. The servers and desktops then use a Generic Volume License Key (GVLK) which let the machine know it needs to find and activate against an internal KMS resource and not go out to activate against Microsoft’s servers.
Apparently even if you have the Volume Licensing agreement, MS doesn’t automatically issue the CSLVK KMS key to you in your portal. You actually have to call them, verify some info, and have them generate a key for you which will then show up in your portal. The whole process took just under 5 minutes for me, and I was able to verify that I saw the key in my portal while I was still on the phone with MS.
To contact them I called 1-866-230-0560, option 4, option 1. That got me directly in contact with a representative that was able to issue the key. (Note: Menu options may change, I called in February 2020)
Jumping back into my KMS server, i tried to import the key directly into VAMT, also known as the Volume Activation Management Tool. This failed. I tried a couple more times, I even reinstalled the VAMT tool from the ADK toolkit. Nothing worked. Apparently though, I found out that this is a know issue. https://docs.microsoft.com/en-us/windows/deployment/volume-activation/vamt-known-issues
The workaround was to the slmgr.vbs tool. Entering the command below, allowed it to get added successfully. Replacing <CSVLK> with my actual key issued by MS. After entered, you’ll see a pop-up message stating that the key has been successfully added.
slmgr.vbs /ipk <CSVLK>
Once I had added my CSLVK, I was able to jump back into a new Windows Server 2019 virtual machine that I had created and use the slmgr.vbs command below to successfully activate the new virtual machine against my KMS server.
I was reformatting a drive for some Veeam backups and was trying to recall what I had set the ReFS allocation unit size to when I initially setup the drive. Well, I could not remember to save my life. Luckily, with a little command line action, it’s easy enough to find out what it was set it to.
The command line tool to use is fsutils. To see what options are available to us when using fsutils, we can run the following command.fsutils fsinfo /?
Using “E:/” as the drive we are checking out, we can run the following line to discover information about the volume itself. fsutil fsinfo volumeinfo E:
To view the specific ReFS info on this drive, we can run the following line. fsutil fsinfo refsinfo E: Take a look at value for the “Bytes Per Cluster”, this is where we can see that when this drive was formatted, it’s allocation unit size was set to 65k. 65k is also the recommended setting for Veeam destinations if you are using ReFS.
