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:””:

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 | No Comments »

11 exim cpanel golden checks for quick mail troubleshooting.

March 19th, 2016 by Andrea Matesi


The following is just some random advice derived from my experience on dealing with email-related issues.

More specifically, here I’ll be referring to exim (a very popular mail daemon), Cpanel/WHM & CentOS.

  1. Check if the user & password combination is correct.
  2. Check if the SMTP Authentication is enabled.
  3. Check if the User’s mailbox is full.
  4. Perform an nslookup of the domain thru a public DNS Server.
  5. Perform an nslookup of the MX RRs thru a public DNS Server.
  6. Verify that the SPF RR is applied to the domain.
  7. Telnet (or putty with the telnet option enabled) to the destination server address to see if it answers.
  8. Check if the domain name is present inside /etc/localdomains.
  9. Check the logs with exigrep /var/log/exim_mainlog.
  10. Check with vi /etc/userdomains
    Look for some blank spaces or broken lines near the domain that is having incorrect authentication data issue error 535
  11. Check whether the folder “etc” within /home/”cpanel-username”/etc/ is owned by cpanel-username:mail
    If it is not then change it with:
    chown username:mail /home/username/etc/ -R

Hope you might find those useful & feel free to share your own special/unique checks on the comments section.


Posted in LINUX, System Administration, Tips and Tricks. | No 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:

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: AND here:

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”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”


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


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 “Local Admin” 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 :”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 :”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 blog and read (…or should I say “decrypt“?), his sensational article:


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


Posted in Microsoft, System Administration | No Comments »

4 useful lsof commands explained

July 12th, 2015 by Andrea Matesi

This short post introduces you 4 useful lsof commands by examples.

Due to their usefulness, I’d like to “remember to use” those commands more often.


lsof -u “username”.

Example running lsof -u root

lsof-u root

The command above will show you all “root’s user” open files.


lsof -a -p “PID”.

lsof -a -p 1

lsof -a -p 1

-a is a simple AND operator. Used this way is the equivalent of “lsof -p 1“.

-p 1 limits the output to PID 1 (usually that is the kernel…). You get PIDs by running the ps command.

When you specify more than 1 lsof -X -Y command switches (ie. “lsof -p 1 -u johndoe“), by default lsof will perform an OR operation (ie. EITHERPID = 1ORUser = johndoe“).

IF you type, say, “lsof -p 1 -a -u johndoe“, lsof will filter your output by “PID = 1ANDUser = johndoe“.


lsof “/var/log/filename.log”.

lsof /var/log/messages

lsof /var/log/messages

lsof with a file parameter will show you who & what daemon is using the file (ie. the “messages“-log file).

On the above screenshot, /var/log/messages is opened by root thru rsyslogd (which has a PID of 1078).


lsof -i :TCP|UDP-PortRange.

[root@host:~]#-> lsof -i :1-100
sshd     1216 root    3u  IPv4  11823      0t0  TCP *:ssh (LISTEN)
sshd     1216 root    4u  IPv6  11827      0t0  TCP *:ssh (LISTEN)
sendmail 1240 root    4u  IPv4  11922      0t0  TCP localhost:smtp (LISTEN)
sshd     1446 root    3r  IPv4  22798      0t0  TCP> (ESTABLISHED)

lsof -i :1-100

The above command (with a space-char after “-i“), queries your system about “what services are running on the first 100 ports”?

If you want to know only what TCP ports are in use, then type:

lsof -i tcp

That’ll show you all the open TCP ports.

My short examples are only the tip of the iceberg of what lsof can do.

lsof is extremely useful and has an extensive (and sometimes arcane) list of options and switches -- check for yourself at the lsof man page:

Posted in LINUX, System Administration | No Comments »

« Previous Entries