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

December 19th, 2015 by Andrea Matesi

Veggies.

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

http://www.grouppolicy.biz/2010/01/how-to-use-group-policy-preferences-to-secure-local-administrator-groups/

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…

image

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

 

image

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).

 

image

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

 

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

image

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.

 

Fish.

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:

http://www.grouppolicy.biz/2010/01/how-to-use-group-policy-preferences-to-secure-local-administrator-groups/2/

 

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

image

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).

image

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:

image

“%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

 

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]
“DefaultUserName”=”Administrator”
“DefaultPassword”=”your-cleartext-admin-pwd”
“AutoAdminLogon”=”1”

  • 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”).
    image
  2. On the Group Policy Management Editor, Expand:
    Computer Configuration”.
    + “Policies”.
    + “Windows Settings”.
    + “Security Settings”.
    + “Restricted Groups”.
    image
  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).

 

lusrmgr.msg.

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”).
    image
  2. On the Group Policy Management Editor, Expand:
    Computer Configuration
    + “Policies”
    + “Windows Settings”
    + “Security Settings
    + “Restricted Groups”.
    image
  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“.

    image

  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.

SRC:

http://social.technet.microsoft.com/wiki/contents/articles/7833.how-to-make-a-domain-user-the-local-administrator-for-all-pcs.aspx

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
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
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 192.168.1.1:22->192.168.1.2:23494 (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: http://linux.die.net/man/8/lsof

Posted in LINUX, 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).

 

Explanation.

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 »

Fast-enable vncserver on CentOS.

January 3rd, 2015 by Andrea Matesi

…Assuming it is already installed (if not then “yum install vnc”).

Launch the server by typing the following on a terminal:

vncserver :1

Then edit ~/.vnc/xstartup as follows:

#!/bin/sh
# Uncomment the following two lines for the normal desktop:
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80×24+10+10 -ls -title “$VNCDESKTOP Desktop” &
gnome-session &

And done!

Posted in LINUX, System Administration | No Comments »

HOW-TO Setup a Windows RESET Image.

December 28th, 2014 by Andrea Matesi

 

 

As promised, today I will continue blogging on how to Setup a Windows RESET Image to Restore your System to a previously working state.

This post builds on my previous ones (reported here for convenience):

1. Best Windows UEFI/GPT partitioning scheme

2. HOW-TO Setup a Windows REFRESH Image.

Please note – the RESET procedure will WIPE all your User Profile Data (including your Desktop, Documents, Pictures, Music, Videos, Etc.).

Basically you will lose everything and your computer will return to a previous (virgin, empty, nil) state.

To put it in military speech --

  • REFRESH is like tactical bombing (with some collateral damage).
  • RESET is like nuking(!).

The main advantage of RESET is that you won’t have to rely on a lost or missing Windows DVD or USB KEY to Restore your computer to a working state.

Use RESET only as a last resort and try other options first – That is especially true since it is your data I am talking about.

 

How-to Setup a RESET Image.

That said, I’ll show you how to setup a RESET Image for your computer first.

image

  • The process starts by taking a copy of the original install.wim Image From your Windows Install Media (ie. DVD, USB KEY) To a folder within your Recovery partition.

In this example I’ll assume that:

  1. Your Recovery Partition is D:\
  2. Your Recovery Folder is D:\Recovery
  3. Your original “install.wim” Image from your Windows Media is usually located into the “sources”-folder.

Once your RESET Image is in place, open an Admin CMD Prompt and type the following commands:

reagentc /setosimage /path D:\Recovery\install.wim /index 1
cacls D:\Recovery /E /R Users
icacls D:\Recovery /inheritance:d

With the “reagentc”-command, you will specify the path to your RESET Image. The “/index 1”-option selects the first Windows Image within your “install.wim“-Image (Windows 8.1 Pro in my example).

You can find the correct image index with “dism /get-wiminfo /wimfile:D:\Recovery\install.wim”.

Also, to prevent damage to your RESET image, use the cacls and icacls commands to remove normal Users’ permissions and to disable inheritance.

 

Now you see me, now you’re dead!

I highly suggest you to test your RESET image.

Proceed as follows:

  1. Install a new application (say 7-zip).
  2. START –> POWER-Button –> RESTART while keeping the SHIFT-KEY pressed.
  3. Boot to WinRE.
  4. Select “Troubleshoot your Computer”.
  5. Select “RESET” to Reset your PC.

After your computer has been reset, your computer will enter the OOBE process.

You will also notice that 7-Zip is missing from the list of installed Programs and all your User Data is gone!

image

1-Star Movie Reviews: Dr. Strangelove

image

 

BONUS – Hide the Recovery Partition.

If you’ve made it that far, I guess then it’s time to hide your Recovery partition from malicious eyes.

That is to prevent you (or s/else) to accidentally write data (& fill-up) your Recovery Partition.

In this case, a few DISKPART commands will do the trick, so open a CMD as Admin and type:

DISKPART
select disk 0
list volume
select volume 1 <- select your “Recovery”-Volume.
remove <- remove the letter assignment (ie. D-Letter).
list partition
select partition 4 <- select your “Recovery”-Partition
set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac override <- Hide the partition.

THAT'S ALL FOLKS!

Posted in Microsoft, System Administration | No Comments »

HOW TO Setup a Windows REFRESH Image.

November 16th, 2014 by Andrea Matesi

 

 

To continue with your discovery into hidden but-not-so hidden Windows secrets, the next step after configuring your Best Windows UEFI/GPT partitioning scheme is to setup a Windows REFRESH Image.

If you are a Windows Laptop or Tablet user, it is likely that your (reputable?!) vendor has already done the hard work for you.

Although if you choose to perform a clean-upgrade to a later version of Windows or you have a blank computer to start with, please be aware that Windows Setup (by default) does not configure for you a (handy!) REFRESH and/or RESET image.

That is (guess what?) so I can write these post!

If you wonder what a REFRESH or RESET image is, let me briefly introduce you these…

A REFRESH Image is a sort of a snapshot of your system-state without any of your 3rd party programs installed, while a RESET Image wipes your whole Windows system to its current defaults.

The only remarkable difference is that:

1. If you REFRESH, you won’t lose your USER PROFILE DATA (your Desktop, Docs, Pics, etc.).

2. IF you RESET, you will lose ALL your USER PROFILE DATA (your Desktop, Docs, Pics, etc.).

Now, if your feel you require further info about those features, search with your fav. search engine then get back!

 

Let’s get to work.

As said at the beginning, consider this post as the continuation of Best Windows UEFI/GPT partitioning scheme, so I will assume that you’ve installed Windows by following my Best Windows UEFI/GPT partitioning scheme post <LINK>.

Once on Windows, you will notice there is a ~16GB empty partition labeled “Recovery”.

This partition is intended to host both your REFRESH and RECOVERY Images (although for practical reasons I’ll be blogging about the RESET Image on a future post).

 

How to Deploy a REFRESH Image to your Recovery Partition.

To Deploy a REFRESH Image to your Recovery Partition, you will rely on “recimg”.

recimg” is a neat command-line utility that allows you to setup and register a REFRESH Image.

Before using recimg (to create a Custom REFRESH Image), please locate the Drive letter that has been assigned to your “Recovery”-Partition (in my example I will assume that is “D:\”).

You can find your Recovery Partition through Explorer, Disk Management or DISKPART (up to you).

Then, on your freshly setup Windows 8.1, open an Admin CMD and type:

recimg /createimage D:\

image

Brace for a long wait, since the above command will create your Custom REFRESH Image based on your (currently running) Windows.

TIP: Install all your fav apps before creating your REFRESH Image Winking smile

  • Once the REFRESH image creation is complete, recimg will also register the image within your WinRE.

After beer, coffee (or whatever you fancy!), test that your REFRESH Image is working.

 

Tactical Bombing.

For example (After the REFRESH Image process is complete):

  1. Install a new application (say 7-zip).
  2. START –> POWER-Button –> RESTART while keeping the SHIFT-KEY pressed.
  3. Boot to WinRE.
  4. Select “Troubleshoot your Computer”.
  5. Select “REFRESH” to Refresh your PC.

After your computer has been refreshed, you will notice that 7-Zip is missing from the list of installed Programs (but no User Data has been harmed in the process)!

I guess that’s about it. Thanks for reading and please share my blog!

On my next article, I will show you how to Setup a Windows RESET Image.

Posted in Microsoft, System Administration | No Comments »

« Previous Entries