Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


Windows Server 2008 R2 Core initial setup (part 2)

Once your Server Core network etc are configured it’s time to enable/ disable Windows features and roles.

To enable/ disable/ list Windows features and roles it’s probably easiest to import the ServerManager module into PowerShell and use the three cmdlets provided. But just in case you are not into PowerShell, or don’t want to install PowerShell and it’s dependency .NET (you are on Server Core and PowerShell & .NET aren’t installed by default there) there are two alternatives.


DISM is short for Deployment Image Servicing and Management. As the name suggests, it’s a tool for managing the disk image using which you deploy Windows. Starting with Windows Vista the installation files of Windows are stored in a (file based) disk image called the Windows Imaging Format (WIM). DISM is a tool that can manage this disk image before it’s deployed to a computer. But DISM is not just about managing disk images before they are deployed; it can be used also to manage a running instance of a deployed image. The latter is what we are interested here.

Disk images prior to deployment are known as offline images. Disk images that are currently running as the OS within which DISM is invoked are called online images. When you are dealing with an online image you also pass the switch /online to DISM.

DISM was introduced with Windows 7/ Windows Server 2008 R2 and has a pretty straight-forward syntax:

The switches of interest to use are /Enable-Feature, /Disable-Feature, and /Get-Features.

To get a list of available features:

To enable a feature:

As you can see, feature names are case sensitive (eugh!!), and DISM doesn’t automatically enable dependent features – we have to enable them ourselves (good in a way coz DISM won’t enable a whole bunch of dependencies without me realizing, but I wish there were a way to say go ahead and enable whatever’s required). In contrast, if you try enabling a feature using PowerShell with the ServerManager module, dependencies are automatically taken care of.

(Update: DISM in Windows Server 2012 and Windows 8 has a /all switch that automatically installs all the dependencies.)

The feature names are also not very intuitive – for instance to enable AD DS you need to enable the DirectoryServices-DomainController-ServerFoundation feature but that’s not very obvious coz of the ServerFoundation tacked at the end of the feature name, which makes you think it might be a scaled down version of AD DS. (Just as an aside: in the specific case of AD DS, even if you don’t enable the afore-mentioned feature yourself, dcpromo automatically enables it as part of its tasks). This TechNet article is helpful in understanding what the feature names are.

I also hate the fact the fact that there are so many switches to type, but hey, at least the names are logical and I am glad DISM doesn’t have any dependencies and works out of the box on Server Core too. PowerShell has much better switches, but you need DISM sort of to enable PowerShell and the ServerManage module features.

Apart from enabling and disabling features, it’s worth knowing that DISM can be used to upgrade between editions. Say if you are running Server Core Standard and want to move to Server Core Enterprise, DISM can do that.

Read more about DISM and upgrading images at this TechNet article and blog post.

Lastly, DISM can also be used to query the installed drivers:

Unfortunately while there is a /Add-Driver switch for adding drivers, it doesn’t work against an online image.


OCSetup is short for Optional Components Setup. This tool was introduced in Windows Vista/ Server 2008 specifically for Server Core. Windows Vista/ Server 2008 had the new modular architecture of roles and features, along with the Server Manager tool (GUI and command line) to manage these. However, Server Manager depends on .NET which is not enabled by default on Server Core, and so the OCSetup tool was provided for Server Core. This tool has a counterpart called OCList that gets a list of the optional components.

The names returned by OCList are same as the ones given by DISM.

Once you’ve identified the features you’d like, enable them using OCSetup:

Similar to DISM, OCSetup too is case sensitive and doesn’t automatically install dependent features. Moreover, it doesn’t give any output. To see whether the feature was enabled, you run OCList again and verify that it’s installed.

OCSetup has a much simpler syntax than DISM, but also doesn’t have the additional features that DISM has. Moreover, DISM is a useful tool to know for creating offline images for deploying on other machines, so it’s worth familiarizing oneself with DISM.

Windows Server 2008 R2 Core initial setup (part 1)

Happened to set up a Server 2008 R2 Core machine today, so here’s a quick overview of the steps I followed.

Install drivers

If you need to install any drivers, browse to the folder containing the inf file and do pnputil –i -a pathtoinffile.

Configure the network

View the network interfaces and IP addresses:

Rename the interfaces:

An alternate way of viewing IP addresses and interfaces, using the netsh command as above:

View & set the DNS servers:

Disable an interface:

Disable IPv6 (thanks to):

Set computer name

Find the computer name (using either of these methods):

Rename (and reboot):

Activate Windows

Enter license key:


I will talk about adding features later.

Exchange 2010 license key via EMS

Since I am in a command-line-o mode nowadays I am trying to do more things using PowerShell. Recently I installed a server and wanted to enter the license key. Usually I’d go to the EMC and do that but this time I tried to find a cmdlet that would let me do the same.

The Set-ExchangeServer cmdlet is your friend for this:

This cmdlet can also be used for settings things such as Error Reporting and joining the Customer Experience Improvement Program. The cmdlet also has a counterpart called Get-ExchangeServer that can be used to see various Exchange server settings.

It’s better to format the output as a list. That will give you more info. Or you can pipe it to the Get-Member cmdlet to see what properties are available and then just select those. For instance:

This cmdlet also accepts the -Identity switch to query a specified Exchange server; or a -Domain switch to query all Exchange servers in a particular domain. If neither of these are specified the cmdlet queries all Exchange servers in the organization.

In contrast the Set-ExchangeServer only works on one server at a time so if you need to target multiple servers you must put the command within a script.

Managing network interfaces with PowerShell v3

Update: Learnt from this StackOverflow post that the cmdlets below are only available on PowerShell v3 running on Windows 8/ Windows Server 2012 (and later). They are not available on PowerShell v3 running on Windows 7/ Windows Server 2008.

Windows Server 2012 comes with PowerShell v3 and that has the ability to manipulate the network interface from within PowerShell. Meaning you can view the IP address, set IP address, change name of the interface, and so on. I find that cool!

I explored these new cmdlets by typing Get-Net at the PowerShell prompt and pressing TAB. This shows all the commands and I kept trying the ones I felt interested in and discovered new ones from reading the help pages.

For starters, Get-NetIPInterface shows you the available network interfaces. You can pass the cmdlet parameters to filter the results in terms of (say) showing only the interfaces that are connected or showing only the interfaces that are assigned an IP from DHCP.


To see the IP addresses, use the Get-NetIPAddress cmdlet:


We can combine the two cmdlets. For instance, to find the IP addresses of the DHCP assigned interfaces one can pipe the two commands: Get-NetIPInterface –Dhcp Enabled | Get-NetIPAddress


To change an interface settings such as enable/ disable DHCP use the Set-NetIPInterface cmdlet.

To assign a new IP address use the New-NetIPAddress cmdlet (this automatically disables DHCP on that interface if it’s enabled). To change the property of an existing IP address (such as the subnet mask, for instance) use the Set-NetIPAddress cmdlet. And To un-assign an IP address use the Remove-NetIPAddress cmdlet.



I find the Set-NetIPAddress cmdlet slightly confusing. One would expect it to be able to set an IP address too, for instance, but it does not work that way. To add to the confusion this cmdlet too has switches similar to the New-NetIPAddress cmdlet to specify an IP Address (the -IPAddress switch) so you’d think it’s possible to set an IP address this way. But don’t be fooled. All this –IPAddress switch does with the Set-NetIPAddress cmdlet is to let you select interfaces matching that IP address.

If you try and set an IP address using the Set-NetIPAddress cmdlet you get an error:


The error message is obvious. You can see the cmdlet is trying to find interfaces matching the IP address you specify – and failing – rather than set that as the IP address of an interface.

Moving on, I like to rename the network adapters in my VMs. That too is possible using PowerShell now. Rename-NetAdapter is your friend!


I also like to disable some of my network adapters. You can do that too now through PowerShell using the Disable-NetAdapter cmdlet.


Would have been handy if cmdlets such as Disable-NetAdapter were a part of Set-NetAdapter (via a switch).

PowerShell is also now cool enough to fiddle with the bindings. So, for instance, if you want to disable IPv6 for one of your interfaces – possible now via PowerShell! Use Get-NetAdapterBinding to see the available bindings (IPv4, IPv6, etc) and disable using Disable-NetAdapterBinding.


Goes without saying – all these Disable-* cmdlets have an Enable-* counterpart too. So you can enable whatever you disable.

This TechNet topic gives a list of all the Network related cmdlets in PowerShell.

When assigning a new IP address to an interface using New-NetIPAddress you can pass a default gateway IP too via the –DefaultGateway switch. If you forget to do that, there’s no way to add a default gateway – perhaps using the Set-NetIPAddress cmdlet as I was expecting. The only alternatives are to remove the IP address via the Remove-NetIPAddress cmdlet and then re-add the IP address but this time specifying the default gateway; or use the New-NetRoute cmdlet to manipulate the routing table directly.

The Get-NetRoute cmdlet can be used to view the existing routing table. And the New-NetRoute can be used to add a new route. To make a route the default gateway set the destination prefix as (for IPv4) or ::/0 (for IPv6). Examples below:




Lastly, there are cmdlets to configure the DNS resolvers. The Get-DnsClient cmdlet shows you DNS configuration information for each interface. It doesn’t show the resolver addresses; rather this cmdlet is about the DNS client itself and so shows information such as the DNS suffixes and the search list for these suffixes. The Get-DnsClientServerAddress cmdlet does what it says – it shows you the resolver server address for each interface – and is probably what most of us will commonly use.


To set DNS resolves you can use the Set-DnsClientServerAddress cmdlet. To specify multiple addresses put them in brackets with the entries comma separated and in double quotes. The double quotes are important because without them the addresses are ignored.


The same cmdlet can be used with a –ResetServerAddresses switch to remove the server addresses.


And that’s more or less it. These cmdlets only touch the tip of the ice-berg, but I think these are the ones most of us will regularly use.

Just to summarize here’s a table with all the cmdlets:

Get-NetIPInterface Shows you the available network interfaces. Can pass parameters to filter the results (e.g. only the DHCP assigned ones).
Get-NetIPAddress Shows you the IP addresses. Again, can filter using parameters.
Set-NetIPInterface Change an interface settings. Such as turn off/ on DHCP, IPv6 neighbor discovery settings, router settings (advertising, packet forwarding), and Wake on LAN.
New-NetIPAddress Assign a new IP address to an interface. Use the –DefaultGateway switch to specify the default gateway.
Remove-NetIPAddress Remove an assigned IP address from an interface.
Set-NetIPAddress Change IP address properties. For instance: change the subnet mask.
Rename-NetAdapter Rename a network adapter.
Disable-NetAdapter Disable a network adapter. To enable use Enable-NetAdapter.
Get-NetAdapterBinding View the network adapter bindings. Such as IPv4, IPv6, Client for Microsoft Networks.
Disable-NetAdapterBinding Disable network adapter bindings. To enable use Enable-NetAdapterBinding.
Get-NetRoute View the routing table.
New-NetRoute Add an entry to the routing table. Use destination prefix as (for IPv4) or ::/0 (for IPv6) to set default gateway.
Remove-NetRoute Remove a routing table entry.
Get-DnsClient View the DNS client settings. Such as DNS suffix, search list, and so on.
Get-DnsClientServerAddress View the DNS client server addresses.
Set-DnsClient Modify the DNS client settings.
Set-DnsClientServerAddress Add DNS client server addresses. Put multiple address as (“x.x.x.x”, “x.x.x.x.”, …"). Use the -ResetServerAddresses switch to remove the server addresses

Now that’s a good reference for me too to check whenever I forget these commands!

Exchange 2010 Prerequisites

Let’s examine the prerequisites for Exchange 2010 on Windows Server 2008 R2.

I hate it when websites or blog posts just give a list of commands to type in without really explaining what they do. You can get a list of Exchange 2010 prerequisites for Windows Server 2008 R2 from a TechNet article but that doesn’t try and give you an idea of what’s happening or why it’s required.

First up, the Windows Server features that are required. The names below are what you would type in using PowerShell.

Exchange Roles & Feature requirements NET-Framework RSAT-ADDS Web-Server, Web-Basic-Auth, Web-Windows-Auth, Web-Metabase, Web-Net-Ext, Web-Lgcy-Mgmt-Console, WAS-Process-Model, RSAT-Web-Server Web-ISAPI-Ext, Web-Digest-Auth, Web-Dyn-Compression, NET-HTTP-Activation, RPC-Over-HTTP-Proxy Desktop-Experience
MB x x x and install Office filter packs
CAS x x x x and enable Net.TCP port sharing
HT x x x and install Office filter packs
CAS, MB x x x and install Office filter packs x and enable Net.TCP port sharing
CAS, HT x x x and install Office filter packs x and enable Net.TCP port sharing
MB, HT x x x and install Office filter packs
CAS, HT, MB x x x and install Office filter packs x and Net.TCP port sharing
UM x x x x
CAS, HT, MB, UM x x x and install Office filter packs x and enable Net.TCP port sharing x
ET x x and ADLDS

NOTE: Before trying to install a feature via PowerShell don’t forget to import the Server Manager module. After that you can enable features using the Add-WindowsFeature cmdlet.

Now on to the features:

  1. NET-Framework installs the .NET Framework. For Windows Server 2008 R2 that’s .NET Framework 3.5.1.
  2. RSAT-ADDS installs the Remote Server Administration Tools (RSAT) for Active Directory Domain Services (ADDS). Installing RSAT-ADDS automatically installs NET-Framework so you don’t really need to specify the latter separately.
  3. Web-Server … RSAT-Web-Server install the IIS web server:
    1. Web-Server installs the IIS 7.5 web server role and also tools to manage this role.
    2. Web-Basic-Auth and Web-Windows-Authinstall the basic and windows authentication modules.
      1. Basic authenticationmeans the users authenticating with the web server provide a username and password. This is the most basic of authentication techniques – hence the name – but has the advantage that it works across all browsers, firewalls and proxies. However, the password is sent from the client to the server unencrypted and so it’s a good idea to use basic authentication over SSL so all the communication is encrypted.
      2. Windows authentication means the users authenticate with the web server using NTLM or Kerberos protocols. This is more secure than basic authentication but has the disadvantage that not all browsers and proxies support it. The advantage is that windows authentication can use the windows username and password of the user trying to access the website and so gives users a seamless experience.
    3. Web-Net-Ext installs .NET Extensibility. Exchange 2010 requires this for PowerShell remoting, which is how cmdlets in EMS (and in turn the EMC) interact with the server. In Exchange 2010 even if you don’t connect to remote machines, the EMS connects to the Exchange server as though it were a remote session. In fact, this uses a virtual directory published by IIS and is one more reason why IIS is required by Exchange. All (remote) PowerShell requests are sent over HTTP and IIS is used for such connections. (This post gives a great example of PowerShell remoting into an Exchange 2010 server using the IIS virtual directory).
    4. WAS-Process-Model installs the Window Process Activation Service (WAS), which provides the process model for IIS. This MSDN Magazine article is a good introduction to process models and IIS (another good article can be found here). Essentially: a process model is the way multiple applications or websites running on an IIS server are managed and coordinated. A process model ensures that the various applications are available for clients and that they don’t interfere with each other. The WAS is a new component, introduced in IIS 7.0, and it makes it possible to use IIS to host non-HTTP applications (IIS being a web-server you would expect it to work with only HTTP applications; but with IIS 7 you can use IIS for non-HTTP applications too and take advantage of IIS’s management features). Exchange features such as Autodiscover and the Exchange Web Services (EWS) (which is an API hosted on the CAS role and can be used by developers to interact with the core Exchange functionality) are built upon the Windows Communication Framework (WCF). The WCF is a non-HTTP application and so requires WAS in IIS, leading to Exchange requiring WAS as a prerequisite.
    5. Web-Metabase installs the IIS 6 Metabase compatibility feature. The metabase is an internal database where IIS stores its configuration information. IIS 7 does away with the metabase and uses XML configuration files instead. Installing the IIS 6 Metabase compatibility feature allows applications, such as Exchange 2010, running on IIS 7 to still use the IIS 6 metabase APIs. Similarly Web-Lgcy-Mgmt-Console installs the IIS 6 management console.
    6. RSAT-Web-Server doesn’t install anything. It’s the Remote Server Administration Tools (RSAT) for IIS but is already installed as part of installing the Web-Server feature.
  4. I don’t think the Mailbox role actually requires all the Web-* features mentioned above. Only the Web-Server feature and the two authentication modules seem to be actually required. But no harm installing the rest!
  5. The Mailbox & Hub Transport roles require the Office 2010 Filter packs to be installed. This is used so the contents of email attachments can be indexed for searching.
  6. Web-ISAPI-Ext … RPC-Over-HTTP-Proxy installs many additional features that are only required by the CAS role.
    1. Web-ISAPI-Ext installs support for ASP.NET and the Internet Server API (ISAPI) extensions. ISAPI extensions are a way for application developers to extend the functionality of the IIS web server and you can read more about them here. The CAS role uses ISAPI extensions to provide forms based authentication in OWA, for instance.
    2. Web-Digest-Auth installs the digest authentication module. Digest authentication sends passwords from the browser to server using a digest hash (so it isn’t as open for all to view as basic authentication). Unlike windows authentication it does work over proxies, but has other disadvantages. More details about the four authentication methods can be found at this great blog post.
    3. Web-Dyn-Compression installs support for compression of dynamic data. This uses bandwidth more efficiently but increases load on the CPU (due to the overhead of compression).
    4. NET-HTTP-Activation enables WCF HTTP activation.
    5. RPC-Over-HTTP-Proxy allows RPC clients to connect to RPC servers over HTTP. Remote Procedure Call (RPC) is how clients such as Outlook communicate with Exchange. RPC-over-HTTP, which is possible with Outlook 2003 onwards, allows this RPC communication to happen over HTTP. The RPC proxy runs on the IIS server and acts as an intermediary between the server and client.
  7. WCF uses a service called the Net.TCP Port Sharing service. This service is installed as part of the WCF, but not enabled. So on CAS role servers, one must enable it manually. Do this through the Services console or using PowerShell: Set-Service NetTcpPortSharing -StartupType Automatic (after you install WCF above)
  8. Lastly, Desktop-Experience installs codecs required for Unified Messaging.
More later …

Missing AD SRV records


In an Active Directory domain the domain controllers register their service records (SRV records) with DNS when they are promoted to become domain controllers. These SRV records are how other machines on the network figure out who the domain controllers for a domain are. They are used, for instance, when a new machine is to be joined to the domain, or when existing domain machines are starting up and need to get a list of the domain controllers.

These SRV records are published at standard locations and have standard names. In the screenshot, for example, the domain in question is contoso.local and you can see there exists a sub-domain called dc._msdcs.contoso.local which contains records showing that the machine dc1-2008.contoso.local provides the TCP based LDAP service for this domain (as in: it is the domain controller for this domain).


Turns out that when you promote a server to be domain controller, if in the server’s network adapter settings you have set it to not register it’s address in DNS (the default is to register the address in DNS so chances are you changed it while fiddling around!) then the server’s SRV records are not created while being promoted to domain controller status. And if this server is the only domain controller in your domain, it pretty much means no one else can join the domain until this situation is fixed.

So what do you do to get the records back? First off, you go and unclear the box which tells the server not to register it’s records in DNS. And then you restart the NetLogon service. The NetLogon service is an important one for domain controllers, and amongst other things it ensures that the SRV records for a domain controller are registered in DNS. By default it registers the records every 24 hours, but obviously you are in a hurry in this case and so restarting the service ensures that the records are registered when the service starts up.

Hope this helps!

Export and Import Group Policy Objects (GPOs)

This is useful if you want to trash your VMs for instance and start afresh. Good to have all your GPOs backed up and handy so you can easily restore to the new domain.

There’s two ways of exporting and import GPOs: you can use the Group Policy Management Console (GPMC) or you can use PowerShell.

Using the GPMC


To backup a GPO: open the GPMC, drill down to the Group Policy Objects container, right click on the GPO in question and select Back Up. Follow the dialog boxes that appear and save the GPO to wherever you want on the computer.

Note that you have to go down to the Group Policy Objects container.  Right clicking on the links to the GPOs from any OU won’t get you the correct menu.

The folder where you backup GPOs to contains sub-folders that contain the GPO files and settings. The sub-folders are named after GUIDs that uniquely identify the instance of the backup. If you take another backup of the same GPO to the same folder, the sub-folder that is created will have a different GUID. Within these sub-folders you can double-click a file called bkupInfo.xml to see the details of the GPO that was backed up.

To restore a GPO: open the GPMC, right click on the Group Policy Objects container and select Manage Backups. In the dialog box that appears set the path to the folder containing the backed up GPOs and then select the GPO that you want to restore.

There is a catch though. You can only restore GPOs to the same domain where they were backed up from. Not domain with the same name, but same domain. And if you try to restore a GPO to a different domain, you get a very uninformative “Failed…” error.

To work around this, you can import GPOs. For that go down to the Group Policy Objects container, create a new GPO, right click the GPO, and select Import Settings. Follow the dialog boxes that appear to give the path of the folder containing your backed up GPOs, select the GPO you want, and import. The difference between import and restore is that the former does not carry over the security settings nor does it restore the links of the GPO.

Using Powershell

Before you can use PowerShell to manage GPOs you must import the grouppolicy module:

After that you use many PowerShell cmdlets to manage GPOs. For instance:

To backup a GPO use the Backup-GPO cmdlet:

Note the output gives you the GPO name, GUID, and a GUID for the backup instance. We encountered the latter when using the GPMC. The sub-folders created in the path that you specify are named with this backup instance GUID.

It is best to specify an absolute path to the cmdlet. If you must specify relative paths, be sure not to start it with a period else the cmdlet throws an error. Even without the period, I find some of these cmdlets give an error.

To restore a GPO use the Restore-GPO cmdlet. Same caveats apply as the GPMC – restores can only be done to the same domain. Else a cryptic error is thrown:

The workaround, as before, is to import the GPO. First create a new GPO, then import:

It is possible to skip explicitly creating a new GPO before importing. Simply add a switch -CreateIfNeeded to the Import-GPO cmdlet and it will automatically create a new GPO with the target name given. Also one can backup/ restore/ import all GPOs by specifying a -All switch to the cmdlet. For instance:

That’s all for now!

Virtual lab setup

Here is a high level overview of how my virtual lab is set up.

Tony Redmond’s “Exchange 2010 Inside Out” book is what inspired my current set up. Previously I had a desktop machine running Debian Linux & KVM with Windows and Linux machines as guests and I would Remote Desktop or SSH into these; but Tony’s book mentioned how cool he found it to be able to have a laptop with all his virtual machines as well as applications such as Word running side by side and it was fascinating that both were just an Alt+Tab away from each other. I too found it a fascinating idea, and I was in need of an excuse to purchase a new powerful laptop as well as move to a system where all my virtual machines were “in hand” and so that’s where I am now.

I purchased a Samsung NP550P5C laptop which I upgraded to 16GB RAM (the laptop has two slots and comes with 4GB in each). It runs Windows 7 and I installed VirtualBox as the hypervisor. I chose VirtualBox as it supports 64-bit guests, unlike Virtual PC, and I had trouble with my initial choice VMWare Server (Windows Server 2008 guests kept crashing upon reboot). I am glad I chose VirtualBox – so far it’s been a great experience and my only wish is that it supported some way of organizing guests in the virtual manager console into folders and let me manage them as a group (automatically start the guests in a particular delayed order, for instance)[Update: VirtualBox 4.2 supports grouping, headless launching, and autostart of VMs with the host system (not on Windows though)].

I have set my Windows 7 host task bar to the left. This way I can maximize the window of the guests and have them as sort of full-screen but with the ability to easily select other apps on the host with a mouse click. Further, I set Ctrl+Shift as the “host key” in VirtualBox, which means when I am in a guest I can press Ctrl+Shift and then Alt+Tab to any other guest or app. Or I can do Ctrl+Shift and then Win+ to switch to that app in the taskbar. I find that very neat.


Here’s a screen shot of a freshly installed guest.

Notice  how all the icons in the host taskbar are grouped except the VirtualBox ones? That’s thanks to the 7+ Taskbar Tweaker which lets me tweak the taskbar in many useful ways. Also, by default if you move the taskbar to any side the icons are large and ugly – but there is a workaround for that. Applying the workaround each time you login (or whenever the taskbar expands back to the large and ugly size as it tends to do sometimes) is a chore so I created a AutoHotkey script that does it for me.

In terms of the guests, I have a WSUS server guest to take care of the Windows updates. This way each guest does not have to keep downloading updates and clog my bandwidth. The WSUS server downloads and caches it. It is also a good experience for me to get familiar with WSUS.

When I think of WSUS I think of a battle tank. It feels that way – slow and lumbering. No fault of WSUS though; it is a very I/O intensive application what with all the downloading and storing in a database and that obviously takes a toll on its performance as a guest. A useful tip for when you install WSUS as a virtual guest is to limit the SQL Server process’s memory usage. The first time I tried WSUS I found that it made all my guests and the host slow and I saw that the WSUS guest was always eating up all the RAM allocated to it. A bit of Googling showed that this was a common complaint and there was a way to limit the SQL Server’s memory usage. I did that and since then WSUS is well behaved. Currently I have set aside a 2GB guest as my WSUS server and limited the memory usage of the SQL Server process to 1GB.

The WSUS server is also my gateway router for the virtual guests. I have many internal networks in VirtualBox (to simulate multiple LAN/ WAN segments) and have assigned each guest two NICs – one on an internal network and another for VirtualBox NAT. When a guest is on the VirtualBox NAT  the host acts as a DHCP server and assigns the guests dynamic IPs from the 10.0.x.0/24 range. The x corresponds to the instance of the NAT interface plus 2, so if your guest has 3 NICs and all three are on VirtualBox NAT then the first NIC will be on the network, the second on the network, and the third on the network. Each NIC will have a dynamic IP from that networks’ address range, and the gateway will be set as 10.0.x.2 and the name server as 10.0.x.3.

It is not necessary to use the dynamic IP assigned by the VirtualBox host. Instead, you can assign the guests static IPs from that network and they will work fine.

In my case, once a guest is up and running I disable – from the guest – the NIC that’s assigned to the VirtualBox NAT. That way all guests are on the internal network with no direct access to the outside network. (I choose to disable the NIC from the guest rather than from the host as it’s easier if I ever want to enable internet access on a particular guest for some quick testing). As mentioned earlier, all guests also have the WSUS server set as the default gateway. And so on the WSUS server I assigned it’s NAT connected NIC a static IP, installed the Routing and Remote Access role, and enabled routing. Thus the WSUS server acts as a router for all the guests on the various internal networks.

Apart from that each domain’s DC also has GPOs that direct all the machines to connect to the WSUS server for updates, change the background to display information from the SysInternals BgInfo tool, and disable the irritating shutdown tracker. The WSUS server is (as of now) a standalone server.

That’s all for now!