Hyper-V V2V: Passthrough Disk to VHD Image.

June 14th, 2016 by Andrea Matesi


Someday I had a VM installed on a passthrough Hard Disk Drive.

Some weekend, instead of going out, I decided I required that bloody drive to experiment "some more" ('though, a compassionate hoarder feeling inside of me didn't want to bork that OS).

My solution was to migrate my Virtual Machine into a VHD image (so I could finally reclaim that unused hdd space back!).

The virtualised OS was an instance of Microsoft Windows Server 2008 R2 SP1 (but your flavour may vary).

Win2k8R2SP1 was installed within a 111GB Passthrough Hard Disk Drive.

A Virtual Machine hosted within a Windows Server Standard 2008 R2 SP1 with the Hyper-V Role enabled was booting off the passthrough Hard Disk Drive.


Endless possibilities.

There are 2 ways (that I know of...), to accomplish the Passthrough to VHD migration:

  1. With Disk2vhd from sysinternals.
  2. With "New Disk Wizard" from Hyper-V (no additional software required).

I found not using additional software was more convenient (but this shall not influence you decision, since I reckon it is just a matter of personal preference).



To migrate a physical Passthrough hard disk drive to a VHD image with disk2vhd, you simply:

  1. Assess the amount of data to be transferred (ie. From & To).
  2. Shutdown the VM to be migrated (make sure you Shut it Down - ie. do not Turn it Off!).
  3. Open "Disk Management" (diskmgmt.msc) on your Hyper-V Host.
  4. Locate the Hard Disk Drive to be migrated.
  5. Update the disk (to be imaged) status to "online" (so the Hyper-V Host can see it).
  6. Win + E Then Paste: "http://live.sysinternals.com/" On your Windows Explorer Address Bar (courtesy of WebDAV!).


Disk2vhd will list all your (hdds') partitions.

  1. Locate your disk's partitions from the "Volumes to include"-list and select the partiotions by putting a checkmark on them.
  2. Click on the "..."-Button to Browse for the location where to save the VHD image of your passthrough hdd (make sure - again - there's plenty of space!).
  3. Click on the "Create"-Button to generate the VHD image of your VM.

Now get some of your favourite nuts while waiting & you're done!


Hyper-V Method.

Here I'll show a step-by-step howto migrate a physical Passthrough hard disk drive to a VHD image with my favourite Hyper-V Method.

Open Hyper-V Manager & Launch the "New Hard Disk Wizard".

yep, even if you wish to "copy" a passthrough...

Click on "New..." and Select Hard Disk (that's right - just as if you wanted to create a "new" Hard Disk).

The "New Virtual Hard Disk Wizard" will start.

Proceed as follows...
Always "as-if"!

On disk type, Select "Dynamically Expanding" (to create a space-"optimized" image - ie. one which takes less space).

Feel free to choose "Fixed" if you want a FULL image (because, you know, you have more than "plenty of space").

Click Next to proceed to "Specify Name & Location".



Make sure you have plenty of space.

Specify the VHD Image Name and Location.

My VHD image has been named famx11 (same as the parent VM). What's your naming convention? Good, stick with it!


Below is the crucial part: when you choose to create a new VHD, you are can either "Create a new blank virtual hard disk" or "Copy the contents of [a pre-existing] physical disk" (even 'though Disk Management reports the disk as OFFLINE!).

There it is!!!

Select your Passthrough Hard Disk Drive you wish to migrate to a VHD.

Here I selected my 111GB "PHYSICALDRIVE2".


Prepare for a nice quarter...

Click on Finish to start the Image creation process.

A new dialog window will show you another meaningless progress bar which I suggest you don't stare at - just grab some chips!

Grab a cuppa!

Once the image creation process has finished, I strongly recommend you to test the image (ie. Before moving it to, say, your NAS).


Always trust but always verify...

To Test you VHD Image, on Hyper-V Manager.

  • Open the VM Settings to which the passthrough hdd is attached to.
  • Remove (but don't delete yet), the passthrough hdd from your VM.
  • Attach the VHD image (ie. replace the passthrough disk with the VHD Image).
  • Start the VM and check that your VM boots as expected.

Did I already tell you that the above is incredibly easy?

Posted in Microsoft, System Administration | No Comments »

How to migrate your Profile From Local User Account To Domain User Account.

May 14th, 2016 by Andrea Matesi


If you want to join your system to an Active Directory Domain, BUT you don't wanna lose your data & restart from scratch (ie. your Desktop, files, settings, shortcuts, you-name-it), here's how.


Gimme fuel.

Before actually doing your real Local User Account to Domain User Account "profile migration", make yourself a favour — do a "test" run first (ie. by creating a new Local "test" User Account) & check for yourself that it works!

For your "test"-scenario:

  • Create a new "test" User Account (BOTH on your local system & your Active Directory Domain Controller).
  • Now login to the Local System w/the "test" Local User Account.
    This way, a new "C:\Users\test" is created on your PC.
  • While logged in as the "test" User, feel free to replicate some of your "REAL" Local User Profile settings (ie. things you wish to migrate to the new Domain-enabled Account, like your "Google Drive"-setup, your Libraries, etc.).

Once you're done playing, it is now time to migrate ("map") your "test" Local User Account to your "test" Domain User Account.

That will retain all your settings and customisations as-is (including your Desktop icons location).

To do that, we'll rely on a wonderful application named User Profile Wizard ("Profwiz.exe" for friends) from ForensIT.


Spark-plug magic.

Proceed as follows:

Once on the Domain:

  • Login to the PC with your "test" Domain Account.

By so doing, you'll get a new (default, empty) "C:\Users\test.domain"-folder on your local system.

  • Now Logout & login as (Local) Administrator Account.
  • Run Profwiz.exe from your Desktop and follow the wizard prompts according to your requirements.
    Namely, make sure to map the Local "test" User to the Domain "test" User.
  • Logout when finished.


Gimme fire.

  • Login to the System w/the "test" Domain Account.

You will notice the "test" Domain Account has all its previous Local "test" User Profile settings untouched!

  • IF the Local "test" User Profile previously had "Local Administrator" privileges, you will notice some apps might not work.

You can grant the test User Profile Local Administrator permissions by providing him Membershit to the (Local) "Administrators" group.

Proceed as follows:

  1. Open Control Panel.
  2. Click on Manage User Accounts.
  3. Browse for the "test" Domain Account -> "Properties" and grant it membership to (Local) "Administrators"-Group.

Or perhaps you might wish to read one of my previous guides on this subject:

  1. 3 ways to grant "Local Admin" permissions to Domain Users.
  2. Secure Restricted Groups to grant Local Admin Credentials to Domain Users.
  3. How to setup Per-Computer “Local Admins” on a Domain.


Gimme that which I desire.

Alright, now that "Fuel is pumping engines" (cit. Metallica), repeat the above with you real user.


Posted in Microsoft, System Administration, Tips and Tricks. | No Comments »

[SOLVED] Warning - The IO operation at logical block address for Disk was retried.

April 16th, 2016 by Andrea Matesi


Someday my Event Viewer started throwing me warnings as follows:


The IO operation at logical block address 3b9e1628 for Disk 1 was retried.

The above error seems due to a timeout while reading (or writing) data to "Disk 1".

Since then, my Event Viewer –> Windows Logs –> System, got flooded!

Broken disk?! Nope...


How to match Disk No. to "System" Event Viewer.

BTW, which hdd is “Disk 1”?

After a fast search, technet pointed me to the following post:


The technet poster says that you can match “Disk 1” by browsing to the following key (on “regedit”):


In my case I found a list of REG_SZ as follows:


As I said, the Warning seems due to a timeout.

I discovered 2 possible solutions to fix the issue.


1.“bcdedit /set disabledynamicktick yes”-Solution.

First, I tried what documented at the following address:


  1. Running the command prompt as admin
  2. bcdedit /set disabledynamictick yes
  3. Reboot the computer.
  • In my case, setting “bcdedit /set disabledynamicktick yes” solved my issue.



If bcdedit didn't solve your error, then you may wish to increase the “TimeOutValue” from the registry, as documented at the following address:”http://support.microsoft.com/kb/2806730”:

To set the disk.sys TimeOutValue value, follow these steps:

  1. Start Registry Editor. To do this, click Start, type regedit in the Start Search box, and then press Enter.
  2. Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk
  3. Locate TimeOutValue.
  4. On the Edit menu, click Modify.
  5. In the Value data box, type the desired number of seconds.
  6. Exit Registry Editor.

The Microsoft Support article suggests to set the TimeOutValue:”no greater than 20 to 30 seconds”.

You are welcome to share what worked for you!

Posted in Microsoft, System Administration | 2 Comments »

Remove & Reset Folder Redirection from a Profile.

February 20th, 2016 by Andrea Matesi


In case you’ve been Folder Redirecting any User’s Home Folders and along the way you've decided it’s not you cake, to restore your User's profile to its original shape, there are some things you can do.

Since Folder Redirection is a complex (and sometimes convoluted) topic, I don’t mean to be 100% exhaustive (but I'll try).


How to Reset Folder Redirection.

To disable Folder Redirection for (any) User Profile,

  • Make sure you first save an additional copy of the profiles' files into a Fat32 External USB Hdd.

Then, assess the nature of the redirected folders:

  • Which Folders have been redirected?
  • Where have they been redirected to?

Once you have an idea of which folders were redirected, on the DC (or on your RSAT Console):

  1. Run gpmc.msc & Locate/Edit the FR GPO.
  2. Make sure your GPO has “Revert files to the original location”-option flagged.
  3. Revert the Group Policy setting for 1 User.
  4. gpupdate /force
  5. Restart the affected workstation.

Provided your GPO has “Revert files to the original location” set to Enabled, the above steps will restore your User's Redirected Folders to their original location.

Do not rush and disable FR for ALL/everyone.

Start small, remove FR from only one User and adjust the procedure for your unique scenario.

If it works then no need to manually restore the profiles from the Fat32 External USB Hdd.

Go on, disable FR for all your Users and you should be done!


What if...

If “Revert files to the original location” is set to Disabled (as per SBS-default - including Windows Server Essentials 2012), then undoing FR won’t revert your User's Folders.

Said in other words, your User's Folders won't be "moved" off the File Server and back into their original location(!).

This is why I’ve urged you to create a copy of your User Profile to a FAT32 Filesystem (so the User's folders permissions get "sanitised").


Manual Restoration :)

Now, IF FR has been applied to the usual (I’d say safe) candidates (let's assume "Documents", "Pictures" & "Downloads"), then the manual restoration process should be easier and shouldn't involve regedit.

Proceed as follows:

  • Disable FR for that specific profile (as described above).
  • gpupdate
  • Reboot the computer.
  • (On the workstation) verify the location of Documents, Pictures & Downloads.

To verify the location of Documents, Pictures & Downloads, on a User Workstation:

  • Win + E & Go to "C:\Users\%username%"
  1. Right Click on each of the redirected folders (ie. Documents, Pictures, Downloads, etc.).
  2. Click on Properties.
  3. Click on the "Location"-Tab to verify the folder location.

Repet Steps 1..3 for each redirected folder to verify the Folders location.

  • IF the Location is not correct (ie. it points to a file server...), Then Click on the "Restore Default"-Button.

That will restore your Redirected Folders to their default locations (ie. "C:\Users\%username%\Documents", "C:\Users\%username%\Downloads", etc.).


My User Profile is a total mess!

If your Favorites and Libraries are broken/missing too, you may restore them as follows:

  • (On Windows Explorer)
  • Right Click on "Libraries" & Click on “Restore default libraries”.
  • Right Click on "Favorites" & Click on “Restore favorite links”.


Still reading?

Now your last step should involve a restore of your offline backup copy.

At the beginning I suggested you to copy the User's Folders into a Fat32 Filesystem.

  • It is now time to restore those files to the Local User's Home.


AppData Roaming AppData Roaming AppData Roaming.

In case Appdata has also been redirected you’re fckued :P, you will have to perform additional steps:

While performing a backup copy, make sure you also copied over the \Appdata\Roaming folder (ie. “C:\Users\%username%\AppData”), please refer to the beginning of the post - "How to reset Folder Redirection".

Assuming you successfully restored \Appdata\Roaming.

  • Run "regedit"
  • Search for all the locations referring to the remote File UNC (ie. \\dc02\home).
  • Manually (and carefully) adjust all the locations accordingly (ie. change each "\\dc02\home"-entry To "C:\Users\%username%\AppData\Roaming").

For reference, you'll find within the following regkeys the User's Paths.

  • [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
  • [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]

Please remember that From Windows XP to Vista+, the default location of some folders have changed (for the better):

Folder Windows XP Path Windows Vista/7/8/8.1 Path
AppData %USERPROFILE%\Application Data %USERPROFILE%\AppData\Roaming
Cookies %USERPROFILE%\Cookies %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Cookies
History %USERPROFILE%\History %USERPROFILE%\AppData\Local\Microsoft\Windows\History
Local Settings %USERPROFILE%\Local Settings %USERPROFILE%\AppData\Local
Documents %USERPROFILE%\My Documents %USERPROFILE%\Documents
NetHoos %USERPROFILE%\NetHood %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Network Shortcuts
PrintHood %USERPROFILE%\PrintHood %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Printer Shortcuts
Recent %USERPROFILE%\Recent %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Recent
SendTo %USERPROFILE%\SendTo %USERPROFILE%\AppData\Roaming\Microsoft\Windows\SendTo
Start Menu (FWIW...) %USERPROFILE%\Start Menu %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu
Templates %USERPROFILE%\Templates %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Templates
Temporary Internet Files %USERPROFILE%\Temporary Internet Files %USERPROFILE%\AppData\Local\Microsoft\Windows\Temporary Internet Files

Happy reg-editing and don't break stuff.

Remember - for every step you take, make sure you can always undo.

As always, expert input welcome.


Shell Folders VS User Shell Folders: http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx


Posted in Microsoft, System Administration | No Comments »

How to setup Per-Computer “Local Admins” on a Domain.

December 19th, 2015 by Andrea Matesi


This post is a humble summary of Alan Burchill's brilliant post published at the following address in 2010:


Alan is the überhero (& self-declared genius...), so please thank him for his precious time and effort.

Alan's methods reconnects to one of my previous articles were I talked about granting Local Admins credentials to Domain Users.

Here: http://www.pwrusr.com/?p=1534 AND here: http://www.pwrusr.com/?p=1681

Despite the method I discussed above are still valid as of today, IMHO, Secure Local Administrators a-la Alan-way is still the Best method.

Withoud further ado, I'll just summarise what he's explained on his post(s).

I’ll also assume you’ve designed a “proper” (best practice) Active Directory structure, namely by creating some OUs to organise “Groups of Computers” (ie.: "Laptops"-OU, "Servers"-OU, etc.).


Red Meat.

The whole point of Alan's article allows you to granularly grant "Local Administrator"-Permissions to select Users, by mapping one to one relationships.

In other words, inside an Active Directory Domain, one designated User should be also "Local Administrator" of his [designated…] Computer - this way all y'all pwrusrs out there can enjoy a certain degree of privileged of freedom :).

Not only that, you can also designate more than 1 User as Local Administrator of the same Computer.


How to setup Per-Computer “Local Admins” on a Domain.

  • The very first step involves creating some Groups inside any of your designated OUs (say "Laptop01_Administrators", "Laptop02_Administrators", etc.).

Inside each of those Groups, you will place the Users capable of Locally Administering their Computer.

The idea here is:

  1. To use as less GPOs as possible.
  2. To avoid the "Restricted Groups" feature offered by Group Policy.
  • Run gpmc.msc, create a new Group Policy Object and link it to your DOMAIN (refer to p.2).
  • "Edit..." your new Group Policy as follows…


1. Browse the “Computer” –> “Preferences” –> “Control Panel Settings” –> “Local Users and Groups” tree.



2. On “Local Users and Groups”, Right Click on the white area and select “New” –> “Local Group”.

By so doing, you will update the “Administrators” Local Group Members (which by default is built in into each computer - including Domain-Joined ones).



3. On the “Group Name"-dropdown, Select “Administrators (built-in)”.


Now “Add…” the built in Administrator Account to the Local Group:


Flag the “Delete all member users” & “Delete all member groups” checkmarks (ie. tick them), then click on the “Add…”-Button, copy/paste “BUILTIN\Administrator” (without quotes) and Press the “OK”-Button twice to confirm your selections and Close the “New Local Group Properties”-dialog.



Next you will specify who will be the Local Administrator for any of your Computers.

Please refer to Alan’s post for a detailed explanation about the settings I’m about to use:



Repeat Steps 1..3 and Add a New Local Group as follows:


Again, Select “Administrators (built-in)” from the "Group Name" dropdown.


This time DO NOT Check the “Delete all member users” & “Delete all member groups” Checkboxes (ie. leave them unchecked).


Click on the “Add”-Button and this time specify the Groups to which you wish to grant “Local Administrators” permissions.


Now, provided your Computer Groups were named as I suggested earlier (at the beginning of this post), you will Add something similar to the following:


“%DomainName%\%ComputerName%_LocalAdmins” (without quotes).

Please note: the previous entry encompasses ALL your Computers Groups (unless you wish to manually specify them, that is).

  • %DomainName% represents your Domain Name.
  • %ComputerName%_LocalAdmins includes all your Computer Groups.

Now you may wish to repeat the previous steps by including the Domain Admins.

While your next step could be to grant your desired Users membership to the “%ComputerName%_LocalAdmins”-Groups (ie. “Laptop01_Administrators”, “Laptop02_Administrators”, etc.).

[BONUS} wash, rinse & repeat for Remote Desktop Users ;-)

[BONUS No.2] Say you wanna be pesky about whom to grant Local Admin Permissions.

In this case, you might choose to designate an additional AD User (“JohnAdmin”), which would have the same rights as the Standard AD User (say “John"), but - in addition, he’d also get membership to the “PC01_LocalAdmins”-Group.

This way, whenever John is prompted by UAC (say b/c he’s trying to setup 7zip or run stuff “As Administrator”), he may just simply type “JohnAdmin” as User (w/related password), without opening a new Support request!

Kudos to Alan Burchill and feel free to comment below.

Posted in Microsoft, System Administration | No Comments »

Thinking of SHA512 for your PKI? Think again.

November 9th, 2015 by Andrea Matesi



  • If you are in the process of deploying a new CA, and you are thinking of issuing Certs that use SHA512 Hashes, think again!

(From https://support.microsoft.com/en-us/kb/2973337):"If you currently use SHA512 certificates, and do not have this update installed, you may have problems in one or more of the following scenarios by using TLS 1.2:

  • Internet Protocol security (IPsec) stand-alone
  • IPSec with DirectAccess
  • Microsoft Lync Server 2013
  • Remote Desktop Services (RDP)
  • SSL websites
  • SSL based VPN
  • Web applications"

(From https://support.microsoft.com/en-us/kb/2973337).

The affected products/features list is "quality vs quantity" (re-read it!) and lots of super-important components will break (including Windows Updates under certain conditions!).

Don't misunderstand me - Computers' security is important, 'though, at times, it is imperative that things "just work".


Lessons learned.

If you seek wider compatibility over stronger security (while provisioning a new CA), then you should consider SHA (or SHA256 given SHA will be decommissioned starting from 2017) and RSA 2048 (or 4094) bits.

If you still seek greater security, then I recommend you to consider SHA256 (or SHA384 if you must), perhaps with Elliptic Curves instead of RSA ('though that will open another possible "can of shiny new eels"!).

Posted in Microsoft, System Administration | No Comments »

Windows XP, Vista, 7, 8/8.1 Auto-Login Howto.

October 18th, 2015 by Andrea Matesi



[UPDATE - 2016/Jul/30 - Windows 10 Support and Recommendations]:


Thanks to Microsoft's policy of backwards compatibility, Windows 10 supports Autologin, so the below "ORIGINAL ARTICLE" instructions still do work.

'Though, before setting up Password-less Autologin on Windows 10, you might wish to investigate if your device supports Windows Hello and (if not), perhaps consider a PIN.

"Windows Hello" is your most secure and most convenient password-less login option.

If you'd like to know more about Windows Hello, please refer to below articles:

  • https://support.microsoft.com/en-us/help/17215/windows-10-what-is-hello
  • https://support.microsoft.com/en-us/help/12455/windows-10-windows-hello-privacy-faq

I'll simply consider Windows Hello as your "best" option.

Windows Hello relies on a special front-facing camera that recognises 3D faces (No, placing a photo in front of your camera WON'T unlock your computer!).

Windows Hello is pretty simple - anytime you watch your computer, the Windows Hello camera recognises your face and automatically unlocks your computer (ie. saving you from having to type the Password). That's it.

  • The most popular Windows Hello device is clearly the Surface Pro 4 (Surface Pro 3 DOESN'T support Windows Hello).

To configure Windows Hello on your computer, please refer to the below article:

  • https://support.microsoft.com/en-us/instantanswers/871186d6-b09d-4b31-bfc3-bb80ce71dc10/learn-about-windows-hello-and-set-it-up

If you don't have a Windows Hello camera, your second best option is a fingerprint reader.

Some popular Windows 7 era laptops have builtin fingerprint readers known to be compatible with Windows Hello.

So, a single finger-swipe will unlock your computer.

  • For the matter, I'm experiencing consistent success with an old HP Pavillion dv6.


Finally, if you lack a Windows Hello camera and a Windows Hello fingerprint reader, before setting up Password-less login, you might wish to investigate if a PIN would suit.

  • A PIN is definitely easier to type on a tablet.

Windows 10 supports a special variant that links your PIN to your Password, so anytime you wish to login, you simply type the PIN on your device and you're good to go.


Active Directory (AD) Domain Password-less login.

Both Windows Hello and PIN are reported as working on domain environments.

After some further testing, I've discovered that, in order to setup autologin to a domain environment, you'll have to specify your registry settings differently (as follows):

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]



Auto-login saves you the hassle of typing your Password after your Windows System has been turned ON (or Restarted).

If you'd like your computer to go automatically to your Desktop (or, uhm...to the new Start Menu), then automatic login is for you.

The good news is - it works with every Windows version (starting from XP and/or Server 2003+ Editions).

Please note - by following this howto, you are:

  1. Seriously lowering (ie. compromising) your Windows System Security.
  2. You're making a potential thief's life easy!
  3. You're saving a minimum amount of time.

Before recurring to such extreme measures, ask yourself the economical value a malicious user could gain by just turning ON your unattended computer or by stealing it (yes, a facebook compromise has serious consequences).

That said, the compromising feature could be handy on a home environment, ie. when you want to share your system with other members of your family.

IF you still feel safe to apply this hack to your Windows system, then proceed as follows:

- Make sure you can edit (ie. add) regkeys to the Registry.

To hack your Registry, you will require Administrative Credentials.

[Obligatory disclaimer] By manually changing your Windows Registry, depending on what you do, your system might not Start anyomore, so:

  • Pay attention to what you're doing.
  • Stick to the instructions.
  • Always make sure you are able to undo the changes in case (ya know...).

Of course I am not to be held responsible for any damages, but I'd be more than happy to fix it for you ;-)

Let's get hands-on.

- To check if you have "Administrator"-Credentials either:
1. Win+R -> control.exe -> "User Accounts" and check if your account is reported as "Standard" or "Administrator".

2. Ask your System Administrator (which I'm sure he'd be more than eager to delete all your accounts...).

Let's get dirty.

- Open Notepad and copy/paste the following text:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

  • Text Change No.1): Locate the string "Administrator" and replace it with you User Logon Name (leave the quotes in place).
  • Text Change No.2): Locate the string "your-cleartext-admin-password" and replace it with your Computer Password (leave the quotes in place).

- Save the above text as "autoadminlogin.reg" to you Desktop (make sure no txt extension is automatically attached to the file name).

- Right Click on your new "autoadminlogin.reg"-file and Select "Run As Administrator".

You'll be prompted to type-in your (Administrator) Password.

- Type the Password and Click on OK to Confirm.

- When Prompted, Click OK to insert your text data into your Windows Registry.

Happy now?

Reboot your Windows system and check if Automatic Windows Login (ie. w/o having to type your Password) works.

This hack will work on every Local (ie.non-domain-joined) & Networked (ie. AD Domain-joined) Windows copy (be it XP, Vista, 7, 8 or 8.1).

Posted in dirty hacks, Microsoft, System Administration | 1 Comment »

Secure Restricted Groups to grant Local Admin Credentials to Domain Users.

September 20th, 2015 by Andrea Matesi


As I said on my previous post titled "3 ways to grant &ldquo;Local Admin&rdquo; permissions to Domain Users":

There are 2 ways to use Restricted Groups.

  • The first way simply adds New Users along the pre-existing Local Administrators Users (within the (Local) "Administrators"-Group).
  • The second way resets (ie. deletes/wipes) ALL the pre-existing Local Administrators Users off the (Local) "Administrators"-Group. Hope that makes sense.

For further details regarding the first way (also referred to as Restricted Groups), please refer to the linked article linked on my first paragraph (above).

In this post I will show you how to deploy Secure Restricted Groups (the second way).


Secure Restricted Groups.

Secure Restricted Groups happens to be more secure, but it is also disruptive at the same time.

It is more secure because it removes all the pre-existing (Local/Domain) Users from the (Local) "Administrators" Group (in case sneaky software tricks your Local Admin Users).

It is disruptive because it removes all the pre-existing (Local/Domain) Users from the (Local) "Administrators" Group (that's not an error).

Worst case scenario - you lose Administrative access to your Windows PC(!).

The second way to use Restricted Groups to grant Local Administrator Permissions could be more confusing to implement (especially if you now know how to implement the first way), because the order of the Users and Groups is reverted.


Secure Restricted Groups requirements.

The Secure Restricted Groups requirements are the same as the Restricted Groups:

  • An Active Directory Domain (SBS or Windows Server 2000+ based).
  • A "Domain Group" whom to grant Local Administrator permissions.
    (In this post I will assume your Domain Group is "G_HomeAdmins").
  • Group Policy.


Secure Restricted Groups on your workstations - automatically.

How to:

  • Wipe clean your workstations' (Local) "Administrators"-Group first.
  • Then force only the Users of your choice as members of the (Local) "Administrators"-Group.
  • Fully automate the above 2 bullet points.

On your Domain Controller Server or from your RSAT management console,

  1. Browse to Administrative Tools -> Group Policy Management –> Locate your Computers OU (ie. “HeadOffice Workstations”) -> R-Click on your Computers OU & "Create GPO & Link it here" (name it, say, “HeadOffice Workstations Secure Local Admins”).
  2. On the Group Policy Management Editor, Expand:
    Computer Configuration”.
    + “Policies”.
    + “Windows Settings”.
    + “Security Settings”.
    + “Restricted Groups”.
  3. On the Right pane of “Restricted Groups”, Right click and Select "Add Group...".
  4. To provide Local Admin Permissions ONLY to the Group of your choice, here TYPE (or copy-paste) "Administrators".
  5. A new "Administrators Properties"-window will popup.
    IGNORE/Skip the second text box area (where it says "This group is a member of:").

    From http://support.microsoft.com/kb/279301 :"any current member of a restricted group that is not on the "Members [of this group]" list is removed with the exception of administrator in the Administrators group. Any user on the "Members [of this group]" list which is not currently a member of the restricted group is added".

    On the new properties window, on the first text box area (ie. the one that says “Members of this group”...), Click on the "Add..."-Button:
    2013-10-02 20_07_17-Remote Desktop Manager [Admin@pwrdc01]

  6. On the New Widow, Click on "Browse...", locate (or copy-paste) "Domain Admins" (ie. the Group you wish to attach Local Admin Creds to) and Click on the Ok-button to confirm.
  7. Run an admin cmd & "gpupdate /force".
  8. REBOOT the Target Computer(s) belonging to the (GPO-linked) OU.


Step No.6 is were you actually grant Local Admin permissions to the Domain Admins.

That'll delete all the Workstation's (Local) "Administrators" Members first,
then it'll ADD "Domain Admins" to the "Administrators" Group.

Next I will show you how Alan's article has "worked" for me.

Posted in Microsoft, System Administration | No Comments »

3 ways to grant “Local Admin” permissions to Domain Users.

August 16th, 2015 by Andrea Matesi


There are three ways (that I know of..), to grant “Local Machine” Administrator credentials to a Windows Domain User:

  1. lusr-method (!).
  2. "Restricted Groups" / Secure Restricted Groups (convenient for that funny bunch).
  3. “Secure Local Administrators” (a-la Alan's way).



to grant “Local Machine” Administrator permissions to a Windows Domain User through lusrmgr.msc:

  1. Remotely login to the User’s Workstation as a “Domain Admin” (or physically sit in front of the User's Windows PC).
  2. Win+R –> “lusrmgr.msc”.
  3. From the Local Users and Groups Snap-in, Browse to Groups, Double Click on the “Administrators”-Group, locate your Domain User Account & grant him/her membership to the “Administrators”-Group.
  4. Repeat 1..3 for each desired Windows Computer.


Restricted Groups.

lusrmgr.msc may work for your "home" domain or lab.

For that funny bunch of your colleagues, you may wish to use a more convenient way to perform the task of granting them “Local Machine” Administrator permissions.

The Restricted Groups-feature provides you more automation than the "lusrmgr.msc"-method (especially in regards to Step 4).

The Restricted Groups does just that - it "restricts" local groups membership to the (domain) Groups of your choice.

There are 2 ways to use Restricted Groups.

  • The first way simply adds New Users along the pre-existing Local Administrators Users (within the (Local) "Administrators"-Group).
  • The second way resets (ie. deletes/wipes) ALL the pre-existing Local Administrators Users off the (Local) "Administrators"-Group.


Restricted Groups / Secure Restricted Groups requirements.

  • Active Directory Domain (SBS or Windows Server 2000+ based).
  • Your "Domain User(s)" have to be members of a "Domain Group" (alas not so common on some SBS environments...).
    On my example, I will assume your Domain User Jack Daniels is a member of  the Group "G_HeadOfficeWorkstationAdmins".
  • Since the Restricted Groups feature is provided by Group Policy, you should also have an OU with some Computers (unless you want to edit the "Default Domain Policy", which, of course you "can do"!).


Restricted Groups on your workstations - in 10 easy steps.

Today I will show you Restricted Groups because it is automated, non-destructive and less confusing to implement.

On my next article, I'll show you how to implement Secure Restricted Groups (which is pretty similar BTW).

  • With Restricted Groups you will automatically add New Users to the (Local) "Administrators"-Group of each Windows PC member of your Domain.

That way, pre-existing Users (ie. already Members of the (Local) Administrators Group), won't be affected at all (which, depending on how you see it, it may represent an advantage OR a disadvantage).

  1. Browse to Administrative Tools -> Group Policy Management –> Locate your Computers OU (ie. “HeadOffice Workstations”) -> R-Click on your Computers OU & "Create GPO & Link it here" (name it, say, “HeadOffice Workstations Local Admins”).
  2. On the Group Policy Management Editor, Expand:
    Computer Configuration
    + “Policies”
    + “Windows Settings”
    + “Security Settings
    + “Restricted Groups”.
  3. On the Right pane of “Restricted Groups”, Right click and Select "Add Group...".
  4. To provide Local Admin Permissions to a Pre-existing Group (ie. say "G_HeadOfficeWorkstationAdmins"), Click on the "Browse..."-Button, locate G_HeadOfficeWorkstationAdmins (the group you wish to attach Local Admin Creds to) and Click Ok to confirm.
  5. A new "Group Name Properties"-window will popup.
    On the new properties window skip/ignore the first text box area (ie. the one that says “Members of this group”...).
  6. Focus your attention to the second text box area, where it says "This group is a member of:"(on the lower half).

    From http://support.microsoft.com/kb/279301 :"The "Member Of" list specifies which other groups the restricted group should belong to".


  7. Click on the "Add"-Button and Type (or copy-paste) "BuiltIn\Administrators" in the Group Membership dialog then Click OK to Confirm.
  8. [Optional] Click again on the “Add…”-Button & type "BuilIn\Remote Desktop Users" & Click OK.
  9. Run an admin cmd & "gpupdate /force".
  10. REBOOT the Target Computer(s) belonging to the (GPO-linked) OU.

Step No.7 is where you will actually grant Local Admin permissions to the members of the Restricted Group.

Step No. 8 is optional because Local Administrators already have Remote Desktop Access Permissions by default, (but if you must!).

Restricted Groups is "just OK" for small domains of (7 - 75) SMB Workstations, but it isn’t really that flexible because it relies only on Groups and OUs.


Secure Local Administrators (a-la Alan's-way).

If you want a preview of “how deep the rabbit hole goes”, then head to Alan’s grouppolicy.biz blog and read (...or should I say "decrypt"?), his sensational article: http://www.grouppolicy.biz/2010/01/how-to-use-group-policy-preferences-to-secure-local-administrator-groups/


On my follow-up article, I will show you how to implement Secure Restricted Groups.



Posted in Microsoft, System Administration | No Comments »

2 correct ways to install RDS apps (formerly TS) on your RDS HOST.

June 13th, 2015 by Andrea Matesi


2 Options.

  • When you need to provision a new Windows program to by multiple Users (ie. that remotely login to the same TS/RDS Host), you have 2 options.

Setup.EXE VS Setup.MSI

  1. If your app comes packaged with a 3rd party installer (generally "Setup.EXE"), you'll need to manually place your TS/RDS Host into "Install Mode".
  2. If your app is offered with a "Setup.MSI"-file, the System will go automatically into Install Mode after you double-click on it & switch back when finished (ie. no need to manually switch to "Install Mode").

So, if you have an msi, just go ahead and install it - it'll automatically be available to your Users ('though check your RDS Host settings/make sure the app is published).


How to properly deploy "Setup.EXE" Applications.

To correctly deploy an application packaged with a third party installer (ie. Notepad++) & in order to make it available to all your Users, on your Terminal Server or Remote Desktop Services Host(s) :

  • Run cmd as admin then switch to "install mode" with the following command:

change user /install

  • Now install your desired application by, say, running "Setup.exe" (follow the installer prompts as usual).

Once the installer has finished, return to (default) "Execute Mode".

change user /execute

Install mode allows you to correctly deploy apps to your Users.


Under which mode am I?!

To know under which mode you currently are, run (On an Admin CMD):

change user /query

As per MS recommendation, don't leave your system in "Install Mode" (see http://support.microsoft.com/kb/186515).



By quoting http://blogs.technet.com/b/perfguru/archive/2008/06/30/how-to-install-application-windows-2008-terminal-server.aspx

"When an application is installed in Install mode, HKEY_CURRENT_USER information is primarily written to the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install

This information is then circulated to HKEY_CURRENT_USER for each user when they log on to the Terminal Server."

Posted in Microsoft, System Administration | No Comments »

« Previous Entries