Holiday time

Since is holiday time (yuppie), I thought to make a theme shift, just to show IT guys don't always spend their time crunching data or tinkering with hardware.

So here you can see my first attempt to get some underwater footage using the new aquired Rollei S-50 ActionCam.

Second footage. No music this time so closer to real feel, you can actually hear the bubbles :)

GUI vs. console - MinShell

When it comes to arguments between linux and windows followers, one of the main items brought to the table mostly by linux fans is the professional look of the linux console, operated by command line, opposed by rich graphics of the windows interface. Of course we are talking here about server flavors and not desktop ones.

The linux console offers a powerful set of commands that (assuming one knows the syntax and area of coverage for most of the common commands very well) will let you do almost anything you want, keep a strict control of what is running and what it does and will keep same strict control over resources like CPU load and memory used, but operating it requires more knowledge and skills.

On the opposite side, a typical Windows Server deployment will offer you a lot of features brought by the Graphic User Interface (GUI), a desktop experience that allows you to easy configure roles and services, even for less seasoned professionals. The easy part is balanced in this case by fewer options and more resource consumption. Basically you instruct the server to play some roles that you want it to but you have no strict control since some so called "next-next-finish" wizards make some decisions on your behalf. And all of this at a higher resource consumption. As a footnote, since I am also using linux on daily basis be sure I will not praise Windows for what it's not worth.

Of course most of the people interested in this matter have heard about the "core" option when installing a Windows Server. But, be serious, how many of you tried to operate a core version of Windows for production purpose ? For a core Windows Server to operate effectively you will need to be a real wizard to replace all the background operations behind the so called "next-next-finish" procedure. Be sure it can be done by using PowerShell but I have seen or known of far more share of linux gurus that PowerShell wizards. The PowerShell part will be covered in another series of posts so, if interested, stay around.

Now what do you think about a flavor of Windows that will be easier to operate than the core version,  but is very close to it, also retaining a minimal graphic interface but have nothing to do with the desktop experience we were used to ? This is called MinShell and I think it's the best compromise between a bare console with absolute control via command line and a full GUI.

What the MinShell brings:

• fewer resources consumption (no real graphic load)
• smaller attack surface (fewer running services)
• smaller patch footprint (no need for extra updates)
• Server Manager (a minimum graphic shell needed to accomplish any management tasks you need)

Now that we established the reasons why one would decide to favor MinShell over full GUI or console it is time to detail how exactly can we switch between GUI, Core and MinShell states of the operating system.

1. GUI to Core

Most of the times, when we prepare a server for holding certain roles in a production environment we can do all the setup and testing phase easier if we do it using the GUI state of the operating system. After we have it done, stable and no other changes needed, it is time to bring the system to a lower state. If further server management or re-configuration operations will be sparse then Core state will be the best choice.

FULL GUI State

CORE State

 

• The easy way to do it is using the graphic interface that is still available, by removing the graphic feats using the "Remove Roles and Features Wizard". Be aware that the reverse operation will not be that easy since you are about to remove exactly the feats that are permitting you to work in graphic mode.

So we follow the next steps:

Open "Remove Roles and Features" from the Server Manager Dashboard

Select the graphical features intended for removal...

... followed by some other dependant features as you can see above.

The rest is linear "next-next-finish", followed by a mandatory restart needed to update the operating system with roles and/or features you added or, in this case, removed.

• The hard way: PowerShell method follows the same principle, identifying the GUI related features and then removing them. In order to do that you need to run powershell.exe, it will open a blue command-line console where we will issue plain text commands.

Discovering the GUI related features is done by using the command bellow:

      Get-WindowsFeature *GUI*

And the result is:

Listing GUI related features

Removing those features is done by running the following commands, one at a time if you want to record and experience what happens at every step:

      Get-WindowsFeature Server-Gui-Mgmt-Infra | Remove-WindowsFeature
      Get-WindowsFeature Server-Gui-Shell | Remove-WindowsFeature

with the shorter alternative:

      Remove-WindowsFeature Server-Gui-Mgmt-Infra
      Remove-WindowsFeature Server-Gui-Shell

or even assembled in one line:

      Remove-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell

After you issue one command you will have to wait and actually see the progress:

Removing feature - progress bar

And then a restart is required.
As a note, you can force a restart after the command completion by placing "- restart" at the end of the previous command line.

Restarting computer as required

No matter what way you will choose, all you have on your console monitor after restart will be the pitch black screen of the Core State and a command prompt. Of course, any roles or features configured prior to Core State will still be available and working as good as they were configured to do.

2.  Core State to GUI

Once you are in Core state there is no graphic interface so we must appeal to PowerShell again. We can bring the PowerShell console up by pressing , opening "Task Manager" And then "Run new task" from the File menu, as you can see in the picture below...

...and then call in the executable "powershell.exe".

Once the console is open we can follow the same steps as we did before, so we identify the GUI related features but we re-add instead of removing them.

In order to do that we use the following commands:

      Get-WindowsFeature *GUI*
      Add-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell
      Restart-Computer

And have the following result:

After restart we are back to full functional GUI.

3. MinShell

As you can already guess, achieving MinShell state is possible:

• from Full GUI by removing Server-Gui-Shell Feature but keeping Server-Gui-Mgmt-Infra
• from Core state by adding only the Server-Gui-Mgmt-Infra and leaving Server-Gui-Shell out

>>  Still working on it. Next we will explore the looks, the benefits and setbacks of MinShell. <<

- Breaking Mirrors -

Windows Software Mirroring - workaround for getting rid of it

• Why no longer needed

If you are a system administrator then every once in a while you will have to handle some badly or improper configured machines. Some of them are the result of inexperienced or uninterested people but sometimes it's the passing of time and advancing of technology that renders previously good solid solutions to a state of being impractical or worthless.

Back in the days when hardware was high priced there were many people or even small businesses that didn't afford to buy fully configured servers. Disk Controllers with RAID capability were among the expensive hardware. So Microsoft took advantage of this fact and came with a basic software based solution for data redundancy: disk mirroring.

I suppose that by reaching this page you already know the background so I will not insist writing about what mirroring does, pros and cons of the software approach or how it can be implemented.

The actual hardware advances of today give us plenty of RAID controllers that fit or are even embedded in workstation motherboards and all that come at modest prices. Moreover, virtualization and cloud technologies are providing us with all the scalability and redundancy we need, to obtain previously unexpected up-times.
So, having a machine that uses Windows software based mirroring will prove today to be more of a drag and it should be replaced with a more solid and up-to-date solution.

• Particular example

My example will follow a real life case that I had to handle about a year ago and I had no time until now to share it. I will of course skip or blur some sensitive info that I am not supposed to disclose but I will try to provide all the technical info needed to understand the procedure and successfully apply it if needed. Of course it will not have a lot of pictures, just a few that I found in my archive, but I hope it will help you as much.

First we need to define the general conditions that brought us the necessity to apply such measure.

So, I happened to stumble upon an old machine running Windows 2008 R2. This machine used to be a real, physical machine, a desktop based one that had two disks that were mirrored using the Windows software mirroring solution, in spite of the fact that those disks were of different capacities (150GB and 500GB).
Then, sometime in the past somebody thought it better be converted to virtual using VMWARE technology. And of course the P2V process was conducted using the magical, never failing "next-next-finish" style, replicating the exact improper disk configuration and having the following result:

Of course the virtual machine was migrated on a real server and the virtual disks are stored on a Data Storage with a huge number of disks, high level RAID array, hot spares, so the software redundancy became so called excessive redundancy that beside unnecessary consuming storage space is also slowing down the machine by using resources to emulate the mirroring process.
The target was to get rid of the bigger disk (500GB) , since the lesser one (150GB) was better calibrated and the used/available space was never an issue.

• Hands-on, first trial

Since I never used software RAID on Windows platforms before I thought I should first go to our friend that lately holds all the answers, meaning some web search.

There were two approaches given for a software mirrored array, to break or to remove. The difference between them is: breaking holds the info on both sides while the remove option keeps only one volume and releases the space on the secondary disk, making it "unallocated free space". So I decided to stick with the safer one, breaking the mirror. The most clear and quick explanation came from Symantec so I have to quote here.

Most inspiring before making any decisions was taking a snapshot of the machine. That snapshot was reverted a lot of times and I advise you to do the same even if this document will spare you of all the setbacks that turned me around.

If you run a quick search about "breaking" a mirror the solution will be repeatedly obvious, within a few clicks' reach but not satisfactory in this particular case. It was something like going to Disk Management, right click on a mirrored volume and choose "break mirrored volume",

 followed by a warning:

But, no matter which of the corresponding volumes I was selecting, I was stuck with the wrong bigger disk remaining the boot one even if in theory the ideea of a mirror is to be able to use any of its members in case the other fails.

The next trial consisted on "physically" removing the 500GB disk from the machine, but that was part of the snapshot and I was not ready to give it up. Next step was to switch places between disks from BIOS, but Windows remembered its preferred disk and booted from it and it was all the same.

There were a lot of trials and fails, I don't remember all of them since a lot of time passed.

After a while I decided to use the msconfig tool to switch from the main boot device to the alternate one and set it as default boot device,

This way we make sure the 500GB disk will no longer be the primary disk from which the operating system will boot. Of course this operation needs a restart and after that we have the alternate system in charge, booting from the secondary disk. After this step any "mirrror breaking" using the GUI resulted in a new error:

• The real catch

Was when I started browsing again for answers. Nothing could be done using the GUI so DISKPART seemed to be the answer. It is a long time since I used command line "fdisk" for dealing with disks and partitions. Since nobody seemed to point in the right direction I started to RTFM, keeping the idea that alternate boot from the disk I wanted to preserve was the line to follow.

So the next step is opening a command line using administrative rights (you should make sure you have that on the currently logged on user or use ) and then use DISKPART:

Here we can select and then see and operate on properties of disks, volumes and partitions.

What we have to do is list the disks, in case we don't know them yet:

list disk

And retrieve any useful info about them:

As we can see, the named DISK0 has 500GB capacity, holds volumes 0,1,2 and has no longer the boot disk attribute.
We can do the same for  DISK1 and get the following info:

As we can see, the named DISK1 has 150GB capacity, holds volumes 0,1,2 as well (mirrored) and also has the boot disk token.

First we tend to get remove of the boot mirror (volume 0), the operation that previously di not work from GUI so we go for it:

And the result can be seen from the GUI as following:

So it is, at least apparently a success. we can do the same with the data volume. But what about the hidden, letterless, puny 100MB partition that doesn't want to be rendered useless ?

I have a limited screenshots reserve from back then so I have to remember and stick to the given scenario. So after this first success we have to gather data:

As you can see the former volumes 0,1,2 are now 1,2,4, so disk0/volume0 was split from the mirror and became disk0/volume4, no longer linked to its twin volume located on disk1. It also holds the data from disk1/volume0 but it is no longer in sync and can be treated as a separate disk from the original.

The same operation will work on the "Data" volume, breaking it the same as we did before.

And here it is:

So the former volume1 on disk0 is now volume5.

But switching the boot from the Disk0 to Disk1 doesn't switch the "System" attribute from the hidden partition (as you can see above). So if we try to apply the same procedure it fails, giving us the same GUI error, "The specified plex is a the current system or boot plex.", this time in console mode, with no further details. No matter if you move the boot partition, the boot info stays in the same place.

So, it is about "boot" or "system"... but the boot part we've taken care of, now we got to bring the system down and put it into the right place which in our case is the secondary disk. If you simply remove the 500GB disk, even if you managed to move the boot in the right place, the system will not be present so it will not boot, no screenshot available for that.

After loads of searching, trying and reverting the snapshot I had to resume to a more careful studying of the DISKPART command. This command designed to work with: disks, volumes, partitions. Since all the operations until now were done at disk and volume level I was suspecting our next step should be about partitions.
If we retrieve the info about the second disk, the one we want to keep, we notice the second volume is still the one being of the type "Mirror" so this volume is still based on both drives but we will try to split them.

Remembering the error message, we have to remove the "System" attribute from the...  plex. So guessing along and passing the disk and volume level, I had to look closer to the partitions. First we have to render them inactive. You can see below that the mirrored single system partition is marked as active:, after breaking

What we have to do is deactivate it then break the mirror. In order to keep the system bootable after splitting the mirror we have to be sure we have at least one active, system partition. And, to be sure of it we must do it before deactivating the system partition. This can be done by using the bcdboot command (full syntax and examples if you follow the link).

bcdboot c:\windows /s X:

To deactivate the partition we run the following DISKPART commands:

- work in progress -

sample text
    sample text 2