Windows Server 8 first impressions (running in VMware Workstation 8)


I enjoy trying out new Operating Systems as soon as they are released, so naturally I had to download Windows Server 8 Beta Evaluation last night when I had an hour or so to spare.


I have installed it in a VM running on VMware Workstation 8.0. The requirements don’t seem to be too high with the most notable resource requirement to me being 512MB RAM. Not much has changed there since 2008 R2 then. The VMware set up was as simple as I imagined – no need to follow any guides, I just went with my gut and created a new VM as a Windows Server 2008 R2 – 64 bit machine, gave it a couple of GB RAM and vCPUs then told it I would install the OS later. After this I added the ISO for the Beta and Powered Up. The Windows 7 desktop wallpaper “fish” makes an appearance on first load and soon you are in the installer. The OS edition I installed is the “Datacenter edition”. I went with the GUI version, as I decided to check the Core edition out another time. Installation is of course very straight forward not too much has changed since 2008 R2. Within 7 or 8 minutes I was up and running at the logon screen.


Installation of Windows Server 8 Datacenter Edition is very straight forward.


Windows 8-esq Login Screen


Things I like so far are –

  • The new design – clearly all stylised to fit in with the Windows 8 and Windows Phone 7 style etc…
  • New Server Manager – manage multiple servers from one area and create Server Groups.
  • Roles and Features guide seems to give you more detail on some roles (such as Active Directory for example)
  • Task Manager improvements – information is easier to read in my opinion – especially the resources / performance data


Annoying things –

  • Server Manager always pops up every time you start up – I’m sure there would be a switch to disable this like Server 2008 though.
  • Start Menu was a little difficult to locate at first! Found it after hunting around a bit though.


The new Server Manager


Of course I had to jump into PowerShell and check it out quickly- I also used PowerShell to quickly join my Server 8 VM to the lab domain.

Add-Computer -Domain domainname -Credential domainname\adminaccount


PowerShell 3.0


Task Manager in the Server 8 Beta


Well overall my first impressions are it looks good, and seems to run well in VMware Workstation. I’m pretty sure it’ll work fine under vSphere 5 and Fusion too. (Of course probably not officially supported yet as it is Beta etc…) I’m looking forward to exploring the new OS in more detail in the coming weeks.


A quick way of finding out where your FSMO roles reside


A nice and simple blog post today, based on finding out where your FSMO roles lie, using just the command prompt. This is useful in a couple of different situations, namely:


  • You don’t want to spend a long time using MMCs / Active Directory Users and Computers to figure out where each of the FSMO roles are.
  • You don’t have easy access to MMCs – for example you are using Windows Server 2008 Core


This command works on both Windows Server 2003 as well as Server 2008 / R2.

Simply type the following in your command prompt window on one of your domain controllers:
netdom query fsmo


Your output should be something like the following, listing the servers which hold each FSMO role.

VMware, Coreinfo and mapping logical CPU cores to physical processors.

Sometimes you may have a requirement due to licensing to ensure a Virtual Machine’s CPU configuration is perfectly set out in terms of “physical sockets”. Or perhaps you want to run an operating system such as Windows Server 2003 SE on your Virtual Machine. By default this VM would be limited to only use 4 cores because of the way VMware tells the operating system that each CPU has only 1 core per socket. (Giving it 4 x vCPUs would be the same as giving a physical Windows Server 2003 SE machine 4 x physical CPUs – the actual CPU limit). Either way, it can be quite useful to verify you have the correct CPU configuration.

Enter Coreinfo. This is a handy command line utility by Mark Russinovich which allows you to dump the information about your current CPU and cache configuration for Windows. Download the utility and execute the following command to gather information about the logical CPU core mapping to physical processor.

coreinfo.exe -c -s

In the case of a single socket, six core CPU (such as the one I have running here) this is the output you will see:


The Logical to Physical Processor Map information in the first section marks each CPU core with an asterisk (*). The next section, lists the Logical Processor to Socket mappings, indicating how many “processor sockets” your machine has and at which location each Processor Core is at (again marked with an asterisk).


If you had provisioned a VM with 4 x vCPUs by default, this would show up with 4 x Sockets and 4 x Physical Processors like so:

Besides being a limiting factor for Windows Server 2003 SE VMs when trying to use 8 x vCPUs (you can’t have more than 4 x “physical” CPUs), this may also be a potential issue with a socket licensed edition of SQL server for example, as you would now have 4 x sockets to worry about with your licensing.


So here is where VMware’s useful extra configuration parameters come in handy. These are basically bits of extra configuration you can add to your VMs, and are stored in your VM’s .vmx configuration file. By simply editing your VM, you can add a configuration option which specifies how many Cores per Socket there are. To do this using vSphere, power off your VM, then edit it’s settings. Go to the Options tab, then General, then Configuration Paramaters.



In this case I have a VM with 4 x vCPUs, which shows up by default with 4 x processor sockets. I want this to be 4 x cores with 1 x socket. So now I would click “Add Row” and in the first empty column, enter: cpuid.coresPerSocket and use 4 as the value in the second column. See this screenshot for specifics (and adjust the value used depending on your desired configuration):



Power up your VM, and run coreinfo again, using

coreinfo.exe -c -s


You should now see that VMware is assigning 4 CPU cores per “Physical CPU socket”. In other words, your VM now has 1 x “physical” processor socket, and 4 x cores. Meaning your single processor application socket is now valid on this VM. Here is the result of assigning my VM a value of 4 for “cpuid.coresPerSocket” when it uses 4 x vCPUs in vSphere:



As you can now see, it has changed from the original configuration where it had 4 x Sockets listed under “Logical Processor to Socket Map” with a “Physical Processor” for each “Socket”, to showing the 4 x “Physical Processors” all on “Socket 0”.


If you are using VMware Workstation, this configuration is easy to do – just edit your VM settings, and look for the dropdown menu under the CPU configuration – change this to how many Processors you want and how many Cores per Processor you will use. (See the screenshot below for an example of 2 x Sockets with 2 x cores per socket):



Well, that is a brief overview of how to look at your Processor configuration (whether you are using a physical machine or a Virtual Machine), and how to change your CPU socket / core configurations using VMware vSphere or Workstation. The two uses I can think of as stated above are for licensing issues, or issues where you are being limited by what your guest OS can handle in terms of physical CPUs. Feel free to chime in, in the comments below if you can think of any other uses this may have, or if spot a mistake anywhere!

Modify your NIC MTU size setting in Windows Registry

A quick and easy blog post today on how to modify your NIC MTU (Maximum Transmission Unit) size setting in the Windows Registry.

By default your MTU won’t be defined in registry. Microsoft state that (Link):

The MTU is usually determined by negotiating with the lower-level driver. However, this value may be overridden.

To change your MTU setting in Windows Server 2003 or 2008 use the following steps:

  • Open regedit as an administrator account on the server in question.
  • Navigate to HKLM\System\CurrentControlSet\services\Tcpip\Parameters\Interfaces\[Choose the interface in question] (Do this by checking the correct IP address is in the settings under this key for the adapter you are configuring)
  • Once you are in the correct key for your interface, right-click and select new DWORD value (32 bit).
  • Call it MTU
  • Give this a decimal value equal to the setting you would like your MTU to be (measured in bytes).

For more information about Maximum Transmission Unit sizes, have a look at the official Wikipedia article.

Here is a screenshot of an MTU setting I made on this server using 1400 bytes as an example. This would obviously be tuned to whatever amount you are wanting to use for your NIC and specific application settings.

Create new mailboxes / AD objects using Powershell & Exchange 2007

Here is something new I learnt today. Using powershell scripting can potentially save you a lot of time performing common day to day tasks. In this example I use Powershell to create a new mailbox and Active Directory user object with Exchange 2007 running in my test environment.

1. First off start by opening the “Exchange Management Shell”. This will load a powershell window for you.

2. Now we need to create a password variable and assign a password string to this in the form of a “SecureString”. Issue the following command in your shell window :

$Password = ConvertTo-SecureString -string “TryPassword123” -asPlainText -Force

3. If you now type “$Password” and press Enter, you should get a prompt back saying “System.Security.SecureString”. This means you your plain text password is now stored as a SecureString variable and is ready to use.

4. Next we will run the command to do all the work (That is add the user and mailbox to Active Directory / Exchange 2007). Issue this command next (substituting the values relevant for your situation of course! :

New-Mailbox -Name “John Smith” -Database “First Storage Group\Mailbox Database” -Password $Password -UserPrincipalName -Alias John.Smith -DisplayName “John Smith” -FirstName “John” -Initials “JS” -LastName “Smith” -OrganizationalUnit “Home Users”

You should get a prompt back giving you a summary of what has been done.

This screenshot illustrates the above few steps :

5. After you have run the New-Mailbox command successfully, run “Get-Mailbox” to get a list of current mailboxes residing on your Exchange 2007 server. This should now show your new mailbox.

Creating Primary and Secondary Domain Controllers (Windows 2003 Server)

I was creating a new Domain the other day for testing purposes and thought I would document the process as I went along to put a short tutorial up over here.

This is how to create a Primary Domain Controller (Windows Server 2003) as well as a Secondary DC to act as a backup. I will not be covering FSMO roles or changing of FSMO roles in this tutorial however. The how-to assumes that you have two freshly installed Windows 2003 Servers.

1. Create your first DC. On your first freshly installed Windows 2003 Server machine, go to Start->Run, then type “dcpromo” then hit enter. Alternatively you can go to the “Manage your server” wizard and add a new Role of “Domain Controller (Active Directory)”. After running dcpromo, click Next till you get to the “Domain Controller Type” page. Here we will select “Domain controller for new domain”.

2. Next we select “Domain in a new forest”.

3. You can now enter your full DNS name for the new domain. I used “shogan.local”. Don’t use your web domain here as this is an “internal domain name”. Use something like “yourcompanyname.local”.

4. For the netbios name, leave as default. It should just be a shortened version of your domain specified in step 3. I believe this to help with compatibility when NT, 95, 98 machines are looking at a Windows 2000 or higher domain.

5. Next you can specify the location of your database and log folders. I usually leave mine in their default location.

6. Same for the Shared System Volume folder. I leave mine as default (C:\WINDOWS\SYSVOL).

7. Next the wizard will check to see if you have DNS installed on this machine. If not, select the second option “Install and Configure the DNS server on this computer”. This is the easiest option and the installation will set DNS up for you.

8. The next screen deals with compatibility. I selected the second option here (Windows 2000 and 2003) as I won’t have any other servers below Windows 2000 or 2003 on this particular domain.

9. Enter your Directory Services restore mode password on the next screen and keep this safe.

10. Continue the wizard and the installation will begin.

11. Once the Active Directory Installation wizard is complete, click Finish, then restart the server.

12. Once it has restarted, you should get a screen stating “This Server is now a Domain Controller”. Click Finish and you are done with the first DC!

13. Next, I go to the second server with a fresh install of Windows 2003 Server.

14. Set your IP addresses up. Now that you have a DNS server on the other DC, you can point this Server’s Preferred DNS address to the IP of the Primary DC we just set up. In this case my Primary DC has an IP of and the second DC we are about to set up gets an IP of

15. Run dcpromo on the new server.

16. This time we are going to choose “Additional Domain Controller for an existing domain” in the Active Directory installation wizard.

17. The next screen asks you for your “network credentials”. Enter your new domain administrator username and password (Set up from the first DC). This should be “Administrator” and whatever password you specified during the install. Enter your domain name specified in step 3 above. For example I used “shogan.local”.

18. Enter the domain name again (shogan.local) in my case on the next screen.

19. Complete the rest of the installation wizard as we did in the steps for the first DC. This just involves specifying log folders etc… I usually leave the rest of the options at their defaults. Once you are done, set up should ask you to restart the server.

20. Restart once complete and login with your domain admin account. You should now have a fully functional secondary DC. Any changes you make in Active directory on either server should now replicate across to the other DC.

Here are the images related to each step of the installation process. Click any thumbnail to bring up the larger version.

Feel free to post any questions or comments in the comments section below.