Error when trying to install Windows Server 2012 on VirtualBox

I’ve discovered lately an error on VirtualBox when trying to install Windows Server 2012 on one virtual machine. It seems that VirtualBox encounters an error when trying to boot the OS from the image file. The error reported is “Your PC needs to restart, Please hold down the power button”:

VirtualBox error

I’ve tried restarting both VirtualBox and my PC and the problem still persists. After searching a bit on the internet, I’ve found the solution by executing VBoxManage setextradata [vmname] VBoxInternal/CPUM/CMPXCHG16B 1 from Powershell. First, you will need to navigate to the location of the VBoxManage tool (C:\Program Files\Oracle\VirtualBox) and then execute the command above. Note that the vmname must be replaced with the actual name of the virtual machine:

Windows Server 2012 error
Now you should be able to successfully install Microsoft Windows Server 2012



Storage Area Network technologies used with Windows Server Editions

Most of today’s organizations use storage subsystems to store data for their users and computers. A storage subsystem is a network device dedicated for storing data and is composed of disk drives and controllers. Many organizations have such devices to provide storage space for their servers. Microsoft Windows Server supports multiple technologies that allows a machine to use logical or physical disks that are part of a storage subsystem. In this article we will talk about the concepts and technologies behind storage devices used with Windows Server Editions:
LUN (Logical unit Number) – is a number used to identify a logical unit that is part of a storage subsystem. A LUN can be represented by a portion of a disk, disk, disk array or a portion of a disk array. A SAN device would provide a LUN for each of the machine’s disk to store their data. A LUN is seen by the Server as a physical disk and must be assigned to a machine before data can be stored and retrieved from it. With Windows Server 2008 and newer editions you can create multiple LUN types, as follows:
Simple – the simple LUN can be used to access only physical drives or potions of physical drives
Spanned – simple LUNs that span multiple physical drives.
Striped – used to improve the I/O operations by writing data on multiple physical disks. Data is written into blocks on all of the disks at the same rate which means that if one of the disks fail, the whole data is lost. This LUN type is used when increased I/O performance is required but remember that stripped LUNs cannot be mirrored, extended and do not offer fault tolerance.
Mirrored – a LUN type that provides fault tolerant technologies by writing the same data on two physical disks. Basically, all read and write operations are made on both drives at the same time. Because data is identically on both disks, if one of them fails than the LUN will use the remaining disk. When the broken disk is replaced, data is automatically written to it and thus the LUN is rebuilt.
Striped with Parity (RAID-5) – fault-tolerant LUN that uses data stripping with parity to store data. IT can be used with minimum of three disks and the RAID is automatically rebuild if one of the disks fails. Parity information is distirbuted among the disks and in case of a failure “subsequent reads can be calculated from the distributed parity such that no data is lost” (Wikipedia)
(from Microsoft’s website)
Using the Provision Storage Wizard you can create LUNs on Fibre Channels or iSCSI connections on a storage device. Once the LUN has been assigned, it will appear as a normal disk in Computer Management console.
Storage Area Network technologies used with Windows Server Editions
iSCSI – is a communication channel that uses initiators to send SCSI commands to s storage device that communicates using the SCSI protocol. Unlike fibre channel connections which use physical connections, iSCSI connections use targets to specify the IP, port and the credentials with which communication between the server and the storage subsystem is made. The iSCSI initiator establishes a connection with the specified target to access all LUNs assigned to it.
Fibre Channel – a LUN assigned to a server that’s using a fibre channel connected directly to the server or cluster. The LUN is accessed using one or more HBA ports (Host Bus Adapter). These ports can be added from the Storage Manager console.
VDS (Virtual Disk Service) – is a technology which allows you to manage storage disks. With VDS, you can use a single utility to manage storage devices both physical and virtual. The VDS hardware provider must be installed prior to creating LUNs. VDS is composed of two elements: the software and hardware providers. The software component manages the interface used to interact with disks and partitions while the hardware component performs the actual interaction with the storage subsystem.
Multipath I/O (MPIO) – is technology that allows a Windows Server to communicate with a storage device using multiple connection paths. It acts like a balancer between the paths and thus ensuring that the communication is not interrupted in case of a failure. MPIO must be installed if the server will connect using multiple iSCSI or HBA connections to the storage subsystem. Once MPIO is configured on a disk, you can enable one of the following policies:
Fail Over Only – uses a single path that is active all the time, the rest are used onl the main one fails. The rest of the paths are in standby and they become active until the active path is again reactivated.
Least Blocks – this load balancing mechanism calculates the best path by comparing the number of data blocks sent. Let’s say you have two I/O operations sent on path 1 that are 50 bytes and 0 bytes sent on path 2. When the next I/O occurs, data will be sent on path 2
Weighted Paths – this load balancing policy sets a priority (weight) to a given path and based on this number, a path would have a higher or lower priority (the larger the number the lower the priority). Each Device Specific Module (DSM) chooses the best path based on the weight number.
Round Robin – this load balancing policy uses all available paths in a balanced way. Simply put, the DSM will choose the first path to send first data blocks, then the second one and so on.

Round Robin with Subset – this load balancing policy allows applications to use a set of specified paths in round robin fashion. Standby paths can be configured if all the primary paths fail.

Least Queue Depth – uses the current I/O requests to calculate the best path. Suppose you have two requests sent on path 1 and 1 request on path 2. When the next I/O operation will occur, data will be sent on path 2.

That’s about it for the technologies involved in the communication between Windows Servers and SAN devices. I hope you’ve enjoyed this article, for any misunderstandings don’t hesitate to use my comments section. Wish you a great day and stay tuned for the following articles.

Automatically Redirect HTTP requests to HTTPS on IIS 7 using URL Rewrite

To automatically redirect HTTP request to HTTPS on a IIS server, you will need to perform the following steps. First make sure that the website has both ports configured in the binding section, just like in the following example:

Web server bindings

Now select the website and click on URL Rewrite section from the menu:

URL rewrite module
Click on Add Rule(s) from the right section of the panel and create a Blank rule:
Windows Server 2008 URL rewrite
Set a name for the inbound rule and configure the pattern to (.*)
IIS URL rewrite
In the Conditions section press Add and set the following:
Condition input : {HTTPS}
Type: Matches the Pattern
Pattern: ^OFF$
Redirect HTTP requests to HTTPS
In the Action menu configure the following:
Redirect HTTP requests to HTTPS on IIS using URL Rewrite
Action type: Redirect
Redirect URL: https://{HTTP_HOST}/{R:1}
Redirect type: See Other (303)
You can also simply add the following lines to the website’s configuration file (web.config):
URL rewrite


How to bind multiple sites with SSL on one IP address and port

IIS would normally require multiple IP addresses or Ports for sites that bind with SSL. This is because before sending site’s header, the SSL handshake is established which encrypts headers. When a request is received by a web server, it needs to know the header information (because it contains sites name) to be able to use the right certificate to decrypt information. If a request is received and the HTTP.SYS layer cannot read the header to use the right certificate to decrypt information, then it will not be able to redirect request to the right website. For this reason, a web server allows one site per IP and Port for HTTPS connections. To get another website working in parallel you will need to use different IP or Port with SSL connections.
To resolve this issue you will need to purchase a wildcard certificate (for example * so you can use all websites that are part of the same domain. Suppose you have two websites named and You will need to add the following configuration in applicationHost.config:
How to bind multiple sites with SSL on one IP address and port


As you can see from the configuration lines, each website contains a SSL binding that listens on all IPs (*) on port 443 but also contains the host name information. I’ve installed a wildcard certificate that is used for all SSL communications. When a request is received by the IIS server, the certificate will be used to decrypt data and read the header information that contains the host name for a specific site. HTTPS.SYS will then know where to redirect the request.

The Windows Boot Process

Once a Windows Desktop/Server machine is booted, the following steps are executed in this order:
BIOS Initialization

  1. The firmware identifies and initializes hardware devices. The CMOS loads the BIOS and then runs POST (power-on-self-test).
  2. The BIOS detects a valid system disk and reads the MBR (master boot record) section.
  3. The Boot manager software (Bootmgr.exe) will be launched which in turn will look and start the Winload.exe process. Once Winload is executed, the OS Loader phase starts.
OS Loader
  1. The Windows Loader Binary (Winload.exe) is used to load system drives that are required to read data from the disk.
  2. Initializes the System to allow the Windows kernel to start its execution.
  3. The system registry hive and the drivers that are marked as BOOT_START are loaded.

OS Initialization

  1. PreSMSS: Kernel Initialization kernel initializes data structures and components and starts the PnP manager which will initialize the BOOT_START drivers that were previously loaded
  2. SMSSInit : Session Initialization – This phase starts when the kernel gives the session manager process (Smss.exe) the right to start its operation. The System will initialize the registry, load and start devices and drivers that are not marked as BOOT_START, and will start the subsystem processes.
  3. WinLogonInit: Winlogon Initialization – Once the SMSSInit phase is completed, the control is passed to Winlogon.exe. In this phase the user logon screen is displayed, the Service Control Manager starts Windows services, and Group Policy scripts are executed.
  4. ExplorerInit: Explorer Initialization – Once the WinLogonInit phase is completed, Explorer.exe is started. During the ExplorerInit phase, the system creates the Desktop Window Manager (DWM) process, which initializes and displays the Desktop.

Enabling Remote Registry Service

Windows Server offers the possibility of remote connecting to a Windows Server to edit its registry. This service is not enabled by default on Windows Server and you must enable it before being able to remotely modify registry settings.
To enable this service you can either RDP on each machine and use the Services console to enable the service or by using a Powershell script which automates this operation.

Enabling Remote Registry Service

You can run the following Powershell command to achieve similar results.
sc \\computername config remoteregistry start= auto
sc \\computername start remoteregistry

You can also use newer Powershell cmdlets like Set-Service or Start-Service. Execute the following command to view the service related commands: Get-Command | Where-Object { $_.Name -like “*service”}
Now that the service has been started, you can open Registry Editor and connect to the remote machine by navigating to File -> Connect and specify the remote server name:

Certification Authority (CA) supported by Windows Server

Certification Authority (CA) supported by Windows ServerIn this article I want to talk about the different types of Certification Authorities that can be deployed in a Windows Server infrastructure. The type of CA you choose to deploy depends on your network requirement and you should study carefully before deciding to deploy such infrastructure. Note that once you deploy an Enterprise or Standalone CA, you cannot change it later. When you install the CA Role on a Windows Server, the wizard will prompt you to select either a Standalone or Enterprise Certification Authority (CA).

Windows Server 2008 offers support for four types of CA:
Enterprise Root 
Enterprise Subordinate
Standalone Root
Standalone Subordinate

Enterprise CA – can be deployed in an Active Directory domain and uses Group Policy to replicate digital certificates within your network. GP is also used to publish certificate revocation lists to AD. Enterprise CA  uses the concept o certificate templates to issue certificates in an automated manner. The way a template is configured determines how data is generated from Active Directory. For example, certificate names are generated from AD, but you’ll need to configure this feature in the certificate template. Enterprise CA offers support for autoenrollment which is used to issue certificates automatically by applying certificate template permissions. When a certificate is requested, the local CA will verify if the user/computer has the necessary permissions to request the certificate. This is achieved by verifying certificate permissions that were previously configured.
Standalone CA – does not require an Active Directory infrastructure. Because Standalone CA does not integrate with AD, all features supported by the Enterprise CA do not apply anymore. For example, a user must provide all needed information when requesting a certificate. Autoenrollment is not supported with Standalone CAs. Administrators must also accept incoming certificate requests manually thus increasing the overall workload of Sysadmins.
A Root CA sits at the top of the PKI (Public Key Infrastructure) architecture. A Root CA is the most trusted entity within the network. These servers must be as secured as possible because if a Root CA is compromised then all certificate infrastructure must be rebuild. Root CAs are usually used to issue certificates for Subordinate CA and are kept offline to ensure highest security is provided.
Subordinate CA sits under the Root CA and is used to issue certificates for users and computers. An enterprise ca use multiple Subordinate CAs within the network. If one of these Subordinate CA is compromised then the Root CA can revoke its certificate thus protecting the rest of the network. Only certificates issued by the compromised Subordinate CA must be replaced.
These are the four types of Certification Authority supported by Windows Server 2008 Editions. Hope this article will serve you well in better understating this technology. We will talk about Windows Server Certificate Authority in future articles so stay tuned for the following posts from IT training day.