RSS Subscription 167 Posts and 2,643 Comments

Default Gateways and Multihomed Edge Boxes

I seem to encounter this issue quite often and felt this topic warrants a dedicated blog post.  The basic point of this post is to explain that you cannot have more than one default gateway on separate NICS on a multihomed server!  Well, technically you actually can, but things won’t work correctly. Now I am not saying that you cannot have multiple Default Gateways on a specific NIC as this is quite possible as Windows will assign metrics so one Default Gateway is given priority over another which provides redundancy.  What I am saying is that you cannot have a Default Gateway on one NIC and then assign a Default Gateway on another NIC.

Any time I have seen Multihomed Servers (OCS Edge, Exchange Edge, ISA, Etc.) malfunctioning, the first thing I’ll do is a  ROUTE PRINT. Quite often, I’ll see several lines that display:

0.0.0.0

0.0.0.0

0.0.0.0

0.0.0.0

That instantly tells me that multiple Default Gateways are assigned.  You should only be seeing one line with 0.0.0.0. The entire point of a Default Gateway is it’s the last resort on where to send a packet.  Now with that in mind, does it make any sense to have multiple last resorts?  No!

So please, put the Default Gateway on only one NIC.  For OCS, I typically put it on the Access Edge NIC.  For Exchange Edge/ISA, I put it on the Internet Facing NIC.  Ok, so you may be thinking, well my external router doesn’t allow RDP traffic…  How am I going to manage my box from the inside since the RDP packets will be blocked at the external firewall?  What I always do on an Edge Server (and you should also be doing this on any multi-homes DMZ/Edge Server including ISA), is create static routes so any internal traffic will go to your internal network from your internal NIC.  It’s essentially creating a fake Default Gateway for only specific subnets (your internal subnets) set on your Internal NIC.

So let’s say you’re setting up an OCS Edge Server and it has 4 NICs:

Access Edge – 10.10.10.100 (DMZ Subnet) – Default Gateway Assigned here

Web Conferencing Edge – 10.10.10.101/24 (DMZ Subnet)

Audio / Video Edge – 10.10.10.102/24 (DMZ Subnet)

Internal NIC – 192.168.200.100/24 (Internal Network)

So how can we get all internal traffic to go out directly through the Internal NIC even though the Default Gateway is assigned to the Access Edge?  As stated before, we’ll create a static route.  So let’s say your internal router is 192.168.200.1, we’ll create a static route using the following syntax

route add 192.168.200.0 mask 255.255.255.0 192.168.200.1 -p

So for anything destined to the 192.168.200.x network (due to mask being 255.255.255.0 it will route to the default gateway of 192.168.200.1.  And Windows is smart enough to see that 192.168.200.1 is on the same subnet as your 192.168.200.100 NIC and assign that as the interface it should send it out of.  Problem solved!

Now what if you have a bunch of internal subnets that have similar address ranges?  Simple!  Supernet your internal networks!

route add 192.168.0.0 mask 255.255.0.0 192.168.200.1 -p

This supernet basically says anything that’s 192.168.x.x (only uses 1st 2 octets since you’re using a mask of 255.255.0.0 otherwise known as /16), send it to the 192.168.200.1 gateway.  And again, Windows is smart enough to see that 192.168.200.1 is on the same subnet as your 192.168.200.100 NIC and assign that as the interface it should send out of.  So if you have a 192.168.200.x, a 192.168.199.x, or a 192.168.198.x network, all those packets will route to the 192.168.200.1 router which will then send the packet to the appropriate subnet. Problem solved!

And the -p stands for persistent.  It means that the static route will survive a reboot.

All the above applies to ISA as well.  Let’s say you’re doing LDAPS authentication which uses port 636.  Your external router may not allow 636.  So by creating the static route to your internal network, the LDAPS traffic won’t be going through your external router and be blocked. It instead will go through your internal router which would most likely be allowing it as Internal Routers are more relaxed in their restrictions.

One thing to take into consideration is that if you are in an environment where the Default Gateways are assigned to all NICs and you modify your server to be properly configured with a Default Gateway on one NIC, make sure that any services such as remote backup on your server are allowed to access over the internet over the ports required for these services or things such as remote backup will start failing.

Share

RDP over SSH using port 443

I recently built my own home lab which lives on Hyper-V managed by System Center Virtual Machine Manager 2008 thanks to my Technet Subscription. I wanted to be able to manage this lab when I am at client sites in case I ever need to test something.  Port 3389 is often scanned by hackers but Server 2008′s RDP is pretty secure just as Server 2003′s RDP was if you always keep your machine up to date due to RDP being encrypted traffic.  But 3389 is often blocked on corporate firewalls.  So I elected to use SSH listening on port 443 to RDP into my lab.  How?  Read on…

After bringing up my server, installing Hyper-V, patching it, and all that other good stuff, I installed FreeSSHD which is a free download here.

The first thing I did was configure FreeSSHD to utilize port 443 instead of port 22.

There are two ways to authenticate when we SSH in.  One is Password Authentication and one is with Public Key Authentication.  I elected to utilize Password authentication only and because of that, I set it to required.  We can still use Public Key Authentication if we want but I decided Password Authentication is good enough for my needs.

I want to utilize port forwarding when I am utilizing an SSH client.  You will see how we take advantage of local port forwarding when I show our Putty configuration below.

We then have to add the account we want to grant access to use SSH.  Because this is a lab, I elected to use the Administrator account.  In a production environment, the Administrator account should not be used as it’s not a good security practice.

The next thing we’ll want to do is set up a port forwarding rule on our home router. Portforward.com is a great site to assist you in how to forward your public IP traffic to your private IP on your lab server for port 443.

This means that any time you want to SSH in, you’ll have to SSH into your public IP.  This can be annoying if you have a DHCP IP.  Instead of paying extra monthly fees for a static IP from your ISP and not contributing to the “we need to go to IPV6″ cause, keep your DHCP address and use something like Dynamic DNS (DynDNS.org).

My home router is a Linksys router in which I am using the DD-WRT software.  After signing up for a DynDNS.org account, you can tell your router to update your Dynamic DNS account so you can always use DNS and know it’ll hit the correct public IP.

Now let’s load up PuTTY and check out the configuration.

We’ll want to specify the hostname we are connecting to as well as port 443 since that’s what SSH is listening on and that’s what we’re port forwarding.

The final configuration step of Putty is to set up our tunnels.

This tunnel essentially allows us to map port 3391 to port 3389. Essentially the way this works is when we PuTTY to our server, we have a secure connection to our server.  Because we enabled local forwarding on our SSHD server, we can create a tunnel rule in PuTTY so if we RDP to port 3391 it will map to 3389 on our server.

So after clicking Open we will get prompted for our Administrator credentials.  You must use an account in which you granted access in FreeSSHD.

After hitting enter and being connected, we can now launch our RDP client.  Because we used our forwarded port from 3391 to 3389, we will RDP to localhost:3391 and because we created that tunnel for our forwarded port, it will automatically connect to ServerIP:3389.  ServerIP is the IP that is defined in the Tunnel settings in PuTTY.

As we can see in the following screenshot, everything works as expected and we can now successfully connect to our lab via port 443, have it be secure, and not have to worry about a port being blocked as 443 is rarely blocked .

There’s one more thing to consider.  Because you are using port 443 for SSHD, you obviously won’t be able to use IIS on the box and have SSL use port 443 or use other applications that listen on 443.  I am using System Center Virtual Machine Manager 2008 which does utilize port 443.  When you install System Center Virtual Machine Manager, it gives you the option to modify the 443 port.  I elected to use port 543 instead.  Everything has worked perfectly and it’s been a month or so since I’ve had my lab up this way.

Share

Some Windows 7 and Server 2008 R2 Information

Mark Minasi over at Exchange Connections presented on Windows 7 and Server 2008 R2 and would like to share with you some information he bestowed onto myself and others.  In addition to what I am including below, Aaron Tiensivu will be coming out with quite a bit of information on Windows 7 and Server 2008 R2 in the coming days.  I’ll update this as he releases some information on his blog that he’s been writing up.

Now keep in mind that Windows 7 and Server 2008 R2 information has only just recently been announced to the public.  Some information below may be incorrect and might’ve been interpreted incorrectly.  So I would definitely not take the information below as 100% accurate until you see it in official Microsoft documentation.

  • Windows 7 will be released at the same time as Server 2008 R2 which is the next major server release.  Server 2008 R2 will be x64 only.  I am personally glad Server products are moving towards x64 only.
  • Aero is being renamed to Aero Shake.
  • Microsoft’s goal is that hardware that runs Vista will also run Windows 7
  • Vista drivers will also be Windows 7 drivers
  • XP has 260 methods to trick applications for application compatibility purposes.  Windows 7 will have 340 methods.
  • PowerShell 2.0 remoting will utilize WinRM for security instead of RPC.  The reason for this is WinRM runs on top of port 80 and is more security focused than RPC such as authentication.
  • .Net Framework will be installable in Server Core which will allow for Server Core PowerShell.
  • In Server 2008, Windows Deployment Services only runs at 1 speed and scales down to the slowest speed it detects on a line and uses that slow speed across the board.  In Server 2008 R2, Windows Deployment Services can run at 3 different speeds and multicast over these 3 different speeds.
  • Dynamic Driver provisioning will remove drivers that are not needed.  This allows you to put more images in 1 VHD (read next bullet) without having to worry about so many unneeded drivers being left on a machine.
  • VHD is being considered the new container format and is on track to replace CAB, WIM, and “maybe” ZIP in the future.
  • User Account Control (UAC) will have a slider (5 settings) to control how intrusive the setting is
  • Read only Distributed File System
  • Direct Access.  This is an Auto VPN type of functionality that uses IPSEC and SSTP.  This will require a Server 2008 R2 RRAS server.  This will be configured by an intuitive wizard.  One unfortunate thing is this will require IPv6.
  • Smarter memory allocation for applications
  • Non-miniport printer drivers (fewer but not all) are being moved from kernel mode to user mode to make the operating system more stable (no blue screens from drivers in user mode)
  • Microsoft is trying to push Powermanagement features such as making each default setting 10% more efficient.  This is a huge increase taking into account all machines that would run Windows 7.  One such advantage is the ability to move operations from 1 core to another if it will not impact performance and allow 1 core to be shut off to save power.  This is called core parking.
  • Branch Cache Lite – Allows to have a machine cache a file and server it out to workstations on its same subnet through Network Discovery Protocol (which replaced Computer Browser in Vista).  This is off by default but can be turned on through GPO.  Caches SMB, HTTP, and HTTPS.
  • Branch Cach Enterprise – Same as Lite but is Server Based.
  • Active Directory – New Domain Functional Level (no details given)
  • Active Directory – New Task Based Administrative Center based off of PowerShell.  All GUI tasks will show their PowerShell code just like the Exchange Management Console does.
  • Active Directory – Recycling Bin that will reanimate all attributes.  One of the problems with reanimating tombstones with a tool such as ADrestore is that when an object becomes a tombstone, it loses a lot of attributes but only really important attributes are retained.  With the recycling bin, all attributes that an object previously had would be retained and reanimated.
  • Active Directory – Best Practices Analyzer (hooray!)
  • Offline domain joining
  • Still no GUI for multiple password policies (I’m quite surprised at this although there are several community GUI tools to do this such as PowerGUI.)
Share

Advanced Group Policy Management 3.0

I’ve been checking out Microsoft Desktop and Optimization Pack a little bit lately.  There are some fantastic tools in here such as:

  • Microsoft Application Virtualization (formerly known as SoftGrid)
  • Microsoft Asset Inventory Service
  • Microsoft Advanced Group Policy Management
  • Microsoft Diagnostics and Recovery Toolset
  • Microsoft System Center Desktop Error Monitoring

In this article, we will focus on one of these new technologies, Advanced Group Policy Management (AGPM).  Just hearing the name of the product, you may think… what’s so Advanced about it?  What more does it give us?  Well, let’s go over some of the “sales” type of talk on what benefits you get from it.  For each topic below, we’ll dive into the GUI and show how the AGPM client provides these capabilities.

Benefits of AGPM

Granular Administrative Control

Robust Delegation Model

Role-based Administration

Change Request Approval

Reduced Risk of Widespread Failures

Offline Editing of GPOs

Difference reporting and audit logging

Recovery of a deleted GPO

Repair of Live GPOs

Enable effective Group Policy change management

Creation of GPO Template Libraries

Subscription to policy change e-mail notifications

Version tracking, history capture, and quick rollback of deployed changes

Working with Delegation

There are two parts to AGPM; the client and the server.  For our lab and demonstration, the Server and Client were installed on the same machine.  AGPM 3.0 is installable on Windows Server 2008.  After installing both the Server and the Client, we utilize the Group Policy Management tool located in Administrative Tools.  When we installed the Server piece, we specified a service account which would be the “Administrator” account for AGPM.  Because this is a test lab, I used the Administrator account which is not best practice in a production environment.

When we open Group Policy Management, we can see we have a Change Control section.  This is the section that allows us to work with the AGPM features.

Clicking on the Domain Delegation Tab will display the Administrator account since that is the service account we specified during installation.

I have a username eshudnow which is only a part of the Domain Users group.  I want to delegate GPO responsibilities to this individual.  Just below where you see the Administrator text above, there is an Add button.  Clicking on this Add button, I specified eshudnow which presented me with the following options for delegation which are pretty self explanatory.

Now when taking a look at the above delegation features, it is important to note that these delegation options are for non-production GPOs.  For production GPOs, you will want to take a look at the production GPO tab.  Essentially, when a GPO from the AGPM archive are deployed to production, any permissions on a GPO other than Read and Apply are removed and the permissions from the Production Delegated are used instead.

Note: SYSTEM and ENTERPRISE DOMAIN CONTROLLERS do not need to be removed.

Taking Control of Production GPOs

So how do we actually take control of a GPO so these delegation settings take affect and actually utilize the features AGPM offers? Let’s go back to the Contents tab.

We can see that these two GPOs are in an Uncontrolled State.  So how can we control these GPOs?  Right-Click on a GPO and choose Control.

We will be able to comment on our reasoning to control the GPO and then the process of controlling this specific GPO will commence.

Controlled GPO Management

Now one thing to keep in mind that when you edit a GPO in AGPM, it is not being modified in production.  You have the ability to check out a GPO so that you and only you can modify a GPO.  You will then check in that GPO and then that GPO can be deployed from the AGPM archive into production.  This allows you to modify GPOs without being worried it will be rolled out to production immediately.  This allows for an easy rollback.

As we can see, the Edit is greyed out.  This means we have to Check Out the GPO so we can edit it.  Once we finish editing or GPO, we Check it In.  This allows someone with the Delegated Authority to approve a GPO and then Deploy it.

So what happens if we modify the GPO in the archive and then decide that we don’t like what we did and just want to scrap the entire archived GPO?  Choose the Import from Production option.  This will copy the production GPO down to our archive and replace the current archived GPO.

Creating a Template

What if we have an existing spreadsheet with standard policies?  Well, forget that spreadsheet…  Let’s just create a new Controlled GPO and turn it into a template.  Actually, let’s go ahead and do this.  Let’s create a GPO called Template and modify a couple options. Right-Click in the empty white space and choose New Controlled GPO.

We’ll create our new template, template.  Original eh?  I’d advise creating this as a Live GPO.  It’s always better to create it offline and choose the Deploy option talked about earlier.  Better safe than sorry I always say.  We can see that we can base this off another template.  This is the whole reason why we are creating the template.  So future GPOs can be based off of this GPO we are creating and then converting into a template.

Once we checked our our GPO, edited it, made our changes, checked in, we will be able to convert our GPO into a template.

To verify that this GPO was converted into a template, we can view it in our Templates tab.

GPO Settings

The nice thing with the Group Policy Management Console (GPMC) is it provides a nice way to view your existing settings and would only show the settings that have been modified.

The way to do this in in AGPM is by viewing the Settings of the GPO and choosing HTML Report.  You can also view the GPO Links to when you Deploy to production.

GPO Differences and Disaster Recovery

One great feature is the ability to view the differences between modified GPOs and be able to revert to the GPO that you feel most comfortable.  The way to do this is by viewing the Differences and viewing a Report.

You can see that you can compare one version of Default Domain Policy Vs another.

If you decide that you want a previous GPO to be deployed to production instead, you can open the History.

This will provide you with a lot of History information.

From here, you can right-click on a previous GPO and choose to Deploy to production.

E-mail Notification

Let’s say you break out the delegation roles across different users.  You have a specific person with Editor privileges and they finish editing a GPO and check it in.  You can set up an e-mail notification to your approvers to notify them to review and approve the change.  To do this, click on the Domain Delegation tab and configure the notification settings.

There are a couple things to note about the settings above.  First of all, the e-mails are not sent encrypted. You can change this through some registry modifications to use SSL encryption.  For information on how to do this, click here.

Another thing to note about the above settings, is that you can specify an SMTP server and authenticate against it.  If you don’t authenticate, you will have to allow relaying on your SMTP server specifically and only for the IP address of the AGPM Server (so you’re not a wide open relay).  If you authenticate, you shouldn’t have to allow any type of relaying on your SMTP server.  If you are running Exchange (and you should, but of course I would say that as I am an Exchange guy!), and you want to allow relaying for whatever reason, you can follow my article here.

Conclusion

AGPM is definitely an interesting product.  After reading about its capabilities, I was intrigued to play and learn the product.  It’s definitely an easy tool to get a hang of and is a very effective tool.  I’d recommend it to anybody who wants more control over their Group Policy Management infrastructure.  For more information, I’d recommend heading over to the Technet Library for AGPM 3.0 here.

Share

Exchange 2007 SP1 and Server 2008 information

wanted to share some of my findings with running Exchange 2007 SP1 on Server 2008. I’ve noticed and heard of several issues and information that I believe people should be cognizant about.

Here are the issues and general information I have heard of and experienced so far that seems to be valuable to share. If you disagree with anything I am sharing, have found it works in a different way for you, and/or want to include your findings and any tidbits of information you may have, please feel free to comment.

  • Hub Transport Server Role fails when IPv6 is disabled on that server – FIXED – If either of these 2 bullets occur, you need to fully disable IPv6 and not just uncheck it.  This requires the same fix as the next section which discusses broken Outlook Anywhere.

    • If IPv6 is disabled prior to the installation of Exchange Server 2007, when installing the Hub Transport Server role, your Hub Transport Server role will fail to install
    • If IPv6 is disabled after the installation of Exchange Server 2007, you may experience some Exchange services failing to start
  • Outlook Anywhere is broken under certain conditions- FIXED @ http://technet.microsoft.com/en-us/library/cc671176.aspx

    • Outlook Anywhere is not working for Outlook 2007 with IPv6 enabled (More information can be found from the following URLs: http://blog.aaronmarks.com/?p=65 and http://www.buit.org/2008/01/04/outlook-anywhere-is-broken-on-ipv6-in-windows-server-2008). More information below.
    • This bug consists of the fact that IPv6 is not listening on the loopback port 6004 (RPC/HTTP Proxy Service). This is causing Outlook Anywhere to fail with Outlook 2007. Not sure if this happens with previous versions of Outlook. The reason for this is because Server 2008 prefers communication using IPv6 over IPv4. Since IPv6 is not listening on port 6004, Outlook Anywhere will fail.
    • TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING
      TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING
      TCP 0.0.0.0:6004 0.0.0.0:0 LISTENING
      TCP [::]:6001 [::]:0 LISTENING
      TCP [::]:6002 [::]:0 LISTENING

  • NTLM seems to be very buggy with Outlook Anywhere. There are lots of reports of Outlook Anywhere NTLM Authentication not being functional when using Server 2008. More information can be found from the following URL: http://blog.aaronmarks.com/?p=65 FIXED in Release Update 8 for SP1 – Update to latest Rollup/Service Pack or type the following command: %Windows%\inetsrv\appcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false
  • OAB Generation fails on Server 2008 Clusters.  More information can be found from the following URL: http://www.spyordie007.com/blog/index.php?mode=viewid&post_id=25 FIXED in Release Update 5 for SP1 – Update to latest Rollup/Service Pack. You may also need to deploy the following hotfix for Server 2008 clusters here in which more information about this hotfix and what it fixes available here.
  • There is an HP Document (http://h71028.www7.hp.com/ERC/downloads/4AA1-5675ENW.pdf) which goes over some testing with varying network latencies using CCR over an OC3 link with a network latency simulator. I wanted to give an overall summary of their findings.
    • 20 ms latency – All the log files were shipped over properly and all CCR databases auto-mounted properly
    • 30-40 ms latency – Some manual mounting will be required to mount all your databases as the latency will prevent all logs to be shipped over fast enough for automatic mounting
    • 50+ ms latency – Log shipping mechanism was out of control
  • In regards to SCR and the network latency topic. SCR is a manual failover mechanism. Because of this, CCR is a lot more dependent on network latency due to its automatic failover mechanism. Microsoft does provide recommendations on how to tune SCR for latency on the Exchange Technet Library which can be found here. The problem here is the article is geared for Server 2003 Networking. As for real world SCR scenarios, I have been told that a mailbox server that contains ~6,000 mailboxes has been successfully failed over to an SCR target across the world over a 200 ms link.
Share

Unattended Server 2008 Base Image Creation using WSIM/Sysprep

In Windows Server 2003, creating a master image in which Sysprep was used to invoke an unattended installation was a fairly straight forward process. It consisted of the following:

  1. Installing Windows Server 2003
  2. Insert Server 2003 CDROM into the CDROM Drive
  3. Navigate to X:\Support\Tools\Deploy.cab
  4. Copy sysprep.exe and setupcl.exe to C:\Sysprep
  5. Copy Setup Manager to C:\Sysprep
  6. Open Setup Manager and create a Sysprep.inf file with the settings you want for an unattended installation
  7. Run Sysprep (Sysprep would automatically detect Sysprep.inf)

In Windows Server 2008, creating a master image is no easy feat. To briefly explain the process (will be detailed throughout the rest of this article), you must first download the Windows Automated Installation Kit (1GB in size) which you can download here, load install.wim, and create a sysprep.xml file. You would finally run the built-in Sysprep utility and tell it to use the sysprep.xml file you just created along with some other options

Once you have downloaded the Windows Automated Installation Kit, you will need to burn it via your favorite burning utility; mine is InfraRecorder which is free. Once it’s burned, go ahead and install it on your Vista or Server 2008 machine (we’ll be using Server 2008). Once it’s installed, open the Windows system Image Manager (Start > All Programs > Microsoft Windows AIK > Windows System Image Manager).

In order to begin creating a Sysprep.xml file, you will need to load a Windows Image File (WIM). Make sure that you are using the Windows Automated Kit Installation version (or above) for Vista and Server 2008 that is linked to in the beginning of this article.  Otherwise the WIM you try to load will be incompatible with the version you are using.

The WIM file we will be using is located on our Server 2008 CD-ROM (X:\sources\install.wim). X refers to the drive letter of your CD-ROM Drive. Proceed to entering your Server 2008 CD-ROM to your Server 2008′s CD-ROM Drive.

Once you have done so, in the Windows System Image Manager, go to File > Select Windows Image.

Browse to the location of the install.wim file. As stated above, this file is located at X:\sources\install.wim. X refers to the drive letter of your CD-ROM Drive.

Once install.wim has been selected, choose Open. This will bring up a new window which allows you to select the version of Windows Server 2008 you will be using as your Master Image. The edition we are currently running Server 2008 on and want to continue using for future cloned guests will be Enterprise. Select Enterprise and click OK to Continue.

We now see our selected Windows Server 2008 Enterprise Image is loaded into Windows System Image Manager.

We will now want to begin the process of configuring our new Answer File which we will name sysprep.xml. In the Windows System Image Manager, go to File > New Answer File.

We now see our newly created Answer File is loaded into Windows System Image Manager.

Now that we have a WIM loaded and an Answer File created, the two are associated with each other and you now have many customizable settings under your Windows Image.

There are many settings I want to change, and I will leave this up to you as the point of this blog entry is to get you started on the basic concepts of getting the Master Image created. At the very least, I will show you how to remove Internet Explorer Enhanced Security Configuration so the Administrators constantly don’t get bogged down with Internet Explorer security prompts.

Note: I take no responsibility for you doing this in production and getting hacked due to you reducing the security of a production machine. Do this at your own risk.

Right-Click on amd64_Microsoft-Windows-IE ESC_6.0.6001.18000_neutral and choose Add Setting to Pass 4 specialize.

Once you add the setting to Pass 4 specialize, you see this setting get added into the Answer File. From here, you can select amd64_Microsoft-Windows-IE ESC_6.0.6001.18000_neutral and modify the settings in the properties. For purposes of this lab, I chose both IEHardenAdmin and IEHardenUser and set them both to false.

Some other popular options you may want to do are as follows:

  • Auto-generated computer name
  • Organization and Owner Information
  • Setting language and locale
  • Setting the initial tasks screen not to show at logon
  • Setting server manager not to show at logon
  • Configuring the Administrator password
  • Creating a 2nd administrative account and setting the password
  • Running a post-image configuration script under the administrator account at logon
  • Setting automatic updates to not configured (to be configured post-image)
  • Configuring the network location
  • Configuring screen color/resolution settings
  • Setting the time zone

These settings are outlined in Brian W. McCann’s sample Sysprep.xml file located here. Even though my article shows you the steps required to create your own Sysprep.xml from scratch, I would still use Brian’s Sysprep.xml file as a baseline as he has popular options that most users are going to want. Why re-invent the wheel? Just copy his XML code, save it into your open Sysprep.xml file, and open it within Windows System Image Manager.

Once you are satisfied with all your modifications to your answer file, save the answer file to C:\windows\system32\sysprep\ as sysprep.xml by pressing Control + S and choosing C:\windows\system32\sysprep\ as the save location and file name as sysprep.xml. Click Save to Continue.

My final Sysprep.xml file which was derived using Brian’s Sysprep.xml file as the baseline looks as follows.

The next step would be to Open a Command Prompt, Navigate to C:\Windows\System32\Sysprep and Type the following:

sysprep /generalize /oobe /shutdown /unattend:sysprep.xml

Once this command is initiated, you will see a window pop up showing Sysprep doing its’ magic.

Once Sysprep is finished working, the system will shut down. You can now clone your shut down machine which will provide you with a nice Sysprep’d copy of Windows Server 2008.

Before I conclude this article, I wanted to express some of my opinions on this entire process. I find it a lot more tedious to do than the method we used for Server 2003. The SetupManager laid out options very nicely and was intuitive to define the settings you wanted. Now, you must go through the process of downloading a 1GB file, burning it, installing it, figuring out all the options you want added to your XML, etc… I personally think that going forward, I will just create a base machine, shut it down without running a Sysprep, clone it, and just run NewSID which can be found here. This is actually what I did for my Exchange 2007 SP1 SCC using Server 2008 Starwind article series. Granted you won’t want to use NewSID if you are doing this in production as you risk the chance of Microsoft not supporting you.

Also, I am not a Microsoft Deployment guy, so I understand that for production, there’s a much larger picture where this tool is a lot more integrated and it is a really great tool when using it with the Microsoft Deployment Tool (MDT). But I am speaking from merely of a perspective of wanting to Sysprep a machine for easy cloning via Virtualization Tools.

Either way, I hope this article helps you out with the process of creating a base image for Server 2008 to assist you in getting new Server 2008 machines up and running as quickly as possible.

Share

Exchange 2007 SP1 SCC using Server 2008 StarWind iSCSI – Part 4

Welcome to Part 4 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is to showcase Server 2008′s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 SP1 Failover Clustering. We first discussed what the lab setup is going to be using VMware Workstation, and then proceeded to the configuration of RocketDivision’s StarWind iSCSI Target software. We then went into Exchange 2007 and did the initial iSCSI Initiator connection to our iSCSI Target.

In Part 2, we prepared our Cluster Nodes by installing any prerequisites needed prior to the cluster formation and Exchange 2007 SP1 installation. When that was complete, we continued with our iSCSI configuration by adding our LUNs to the Cluster Nodes, partitioned these LUNs, formatted these LUNs, and ensuring that shared disk storage was working as intended.

In Part 3, we formed our cluster beginning with Node A followed by Node B. Once our cluster was formed, we will proceed with configuring the cluster to ensure optimal operating for our Exchange server. This consisted of cluster network configuration, quorum configuration, etc. Once configuration was completed, we validated cluster operations. This included testing failover.

In this final Part, we will install Exchange into our Cluster. The first step will be to install the Active Clustered Mailbox Role followed by our Passive Clustered Mailbox Role. We will then proceed with how to manage our new Exchange Cluster.

Part 1

Part 2

Part 3

Part 4

Active Node Exchange 2007 Cluster Installation (NodeA)

Final Preparation

We have finally reached the point where we will install Exchange 2007. Don’t forget that one of the prerequisites is to already have a Client Access Server and Hub Transport Server deployed. If you have not done this yet, I suggest you go do this before proceeding.

Insert your Exchange 2007 SP1 media (SP1 media required) and insert it into our Active Node. In the case of this lab, we are using VMware, so I will be mounting an ISO image to our Active Node (NodeA).

Please ensure that NodeA is currently the Active Node before proceeding. Go to Start > Administrative Tools > Failover Cluster Management > Expand our Cluster > Nodes. Once here, we can view both Nodes and see what disks they currently own.

If NodeA does not currently have ownership of our Database and Disk Quorum disk, run the following commands:

Cluster group “Available Storage” /move:<ActiveNodeName>

Cluster group “Cluster Group” /move:<ActiveNodeName>

Note: There are two Cluster Groups. The first is Available Storage which contains our Database Disk. The second is the Cluster Group which contains our Quorum Disk. It is only essential that NodeA owns the Database disk for installation. For safe measures, I still like to make sure the node we are working on owns both the Database and Quorum Disk.

Installation

Run Setup.exe and choose to Install Exchange Server 2007 SP1. This will bring you to several Pages in which you should review, accept, and continue. These pages include the Introduction Page, License Agreement, and Error Reporting, . Review this information and click Next to Continue.

Once you have reached the Installation Type page, select Custom Exchange Server Installation. We will want to use this option because the Typical Exchange Server Installation installs the Hub Transport Server Role, Client Access Server Role, and Mailbox Server Role. Because we are installing the Mailbox Server Role on a Cluster, we are limited to installing only the Mailbox Server Role. This is the reason why we have installed a Hub Transport Server and Client Access Server on another server prior to installing the Mailbox Server Roles on our Cluster Nodes. Click Next to Continue.

At the Server Role Selection page, choose Active Clustered Mailbox Role. As you can see, all other options have been greyed out and you are forced to install the Management Tools. Click Next to Continue.

At the Cluster Settings page, choose Single Copy Cluster. Then specify the name of the Clustered Mailbox Server Name. This is the name your users will see when specifying what server their mailbox is housed on. Finally, choose the path your database files will be installed. You cannot choose the root path and will be forced to create a subfolder. Click Next to Continue.

Select the IP Address that the Cluster Mailbox Server (CMS) EXServer01 will listen on. In the case of this lab, NodeA uses 192.168.119.160, NodeB uses 192.168.119.161, so we will use 192.168.119.162. We do not need to specify a Second Subnet as we are not deploying our Cluster across multiple subnets. Click Next to Continue.

Choose your Client Settings. If you have computers running Outlook 2003 or earlier or Entourage, choose Yes. Otherwise, choose No. If the wrong option is chosen, don’t worry, you can always add public folders once Exchange is installed. Click Next to Continue.

You will begin to see Readiness Checks being run for both the Mailbox Role as well as the Clustered Mailbox Server. Once this is completes successfully, click Install to Continue. If you have any failures, those failures will need to be remedied prior to continuing with the cluster installation.

Installation will commence. Upon a sucessful instatllation completeion, you will see status of all installation steps shown as Completed. If cluster installation has been unsuccessful, troubleshooting will need to ensue to ensure you can get Exchange installed on the cluster successfully. Clear the check box, “Finalize installation using the Exchange Management Console.” Click Finish to continue.

You will be prompted to reboot, but do not reboot. There is one step you will want to do prior to a reboot. Open the Exchange Management Shell (Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell).

We will now stop the CMS by running the following command:

Stop-ClusteredMailboxServer <CMSName> -StopReason Setup -Confirm:$false

You may now proceed to reboot NodeA. One thing to note, is that when you reboot NodeA, the disks will be moved over to NodeB which does not have Exchange installed. Because of this, once NodeA is back up, you will want to move the CMS group, Available Storage group, and Cluster Group group back to NodeA.

To get a list of the existing Cluster Groups that are installed, type the following command in the Command Prompt:

Cluster Group

As we can see, the Cluster Groups successfully moved over to NodeB. The reason why we wanted to turn off the CMS prior to shutting down, is because NodeB does not have Exchange installed and we don’t want the CMS try attempt to come online.

Run the following three commands to move all three groups back over to NodeA:

Cluster group “Available Storage” /move:NodeA

Cluster group “EXServer01″ /move:NodeA

Cluster group “Cluster Group” /move:NodeA

We will now want to move the storage that is currently in the Available Storage group over to the CMS group, EXServer01. The Database disk, named database, is the only disk currently in the Available Storage group. To do this, we will run the following command:

Cluster res “Database” /move:”EXServer01″

Continue by making the Database disk a dependency of our Exchange Database. To find out how you will want to format the Database name for the dependency, open up the Failover Cluster Management MMC. Expand our Cluster > Services and Applications > CMS (EXServer01).

Take a look at the highlighted text. That is the name of our Database we will use in our Cluster dependency command. We will now want to make the Database disk a dependency of our Mailbox Database by running the following command:

Cluster EXCCLUS01 res “First Storage Group/Mailbox Database (EXServer01)” /AddDep:”Database”

The final configuration of NodeA is to configure the physical disk resource policies so that a failure of a disk resource does not cause failover of the CMS to another node by running the following command:

Cluster EXCCLUS01 res “Database” /prop RestartAction=1

Passive Node Exchange 2007 Cluster Installation (NodeB)

Final Preparation

Insert your Exchange 2007 SP1 media (SP1 media required) and insert it into our Passive Node. In the case of this lab, we are using VMware, so I will be mounting an ISO image to our Passive Node (NodeB).

Please ensure that NodeA is currently the Active Node before proceeding. Open a Command Prompt and type the following command:

Cluster group

We should see NodeA as the owner of all three Cluster Groups. If NodeA does not currently have ownership of all the Cluster Groups, run the following commands:

Cluster group “Available Storage” /move:NodeA

Cluster group “EXServer01″ /move:NodeA

Cluster group “Cluster Group” /move:NodeA

Installation

Run Setup.exe and choose to Install Exchange Server 2007 SP1. This will bring you to several Pages in which you should review, accept, and continue. These pages include the Introduction Page, License Agreement, and Error Reporting, . Review this information and click Next to Continue.

Once you have reached the Installation Type page, select Custom Exchange Server Installation. We will want to use this option because the Typical Exchange Server Installation installs the Hub Transport Server Role, Client Access Server Role, and Mailbox Server Role. Because we are installing the Mailbox Server Role on a Cluster, we are limited to installing only the Mailbox Server Role. This is the reason why we have installed a Hub Transport Server and Client Access Server on another server prior to installing the Mailbox Server Roles on our Cluster Nodes. Click Next to Continue.

At the Server Role Selection page, choose Passive Clustered Mailbox Role. As you can see, all other options have been greyed out and you are forced to install the Management Tools. Click Next to Continue.

You will begin to see Readiness Checks being run for both the Mailbox Role as well as the Clustered Mailbox Server. Once this is completes successfully, click Install to Continue. If you have any failures, those failures will need to be remedied prior to continuing with the cluster installation.

Installation will commence. Upon a sucessful instatllation completeion, you will see status of all installation steps shown as Completed. If cluster installation has been unsuccessful, troubleshooting will need to ensue to ensure you can get Exchange installed on the cluster successfully. Clear the check box, “Finalize installation using the Exchange Management Console.” Click Finish to continue.

Once you have reached this step, congratulations, your Exchange Cluster has finally been fully deployed. You will be prompted to reboot. Go ahead and do so.

All there is really now is to start the CMS back up, and you’re done; besides general configuration. To start the Exchange CMS, open the Exchange Management Shell (Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell).

We will now start the CMS by going on NodeA and running following command:

Start-ClusteredMailboxServer <CMSName> -Confirm:$false

Just to ensure that all Cluster Groups are online, run the following command:

Cluster Group

Post Installation

Generally, now would be the time to go do your general configuration. This includes licensing, configuring the Autodiscover Service, set Quotas, etc…

Before we do any of that, let’s make sure that the CMS will fail over to to NodeB. You can use the Cluster Group /move command, but it is best practice to use the Exchange Management Shell (EMS) command, Move-ClusteredMailboxServer. This is required in CCR Clusters due to the Cluster command not being Microsoft Cluster Service Aware which can ultimately break the log shipping mechanism.  You can read more about using Cluster Group /move vs Move-ClusteredMailboxServer here.

Let’s move our CMS over to NodeB by running the following command in the EMS:

Move-ClusteredMailboxServer EXServer01 -MoveComment “Failover to NodeB” -TargetMachine:NodeB -Confirm:$False

After running this command, go into the Failover Cluster Management MMC. Expand our Cluster > Services and Applications > CMS (EXServer01). There are a few things to take note of here. There are two preferred owners of this CMS, NodeA and NodeB. This means, if NodeA is the current owner of the resources of this CMS and it goes down, NodeB will take over. The same goes in a vice versa scenario.

As we can see, the current owner is NodeB which means the Move-ClusteredMailboxServer command was successful. All the “Other Resources” which are the Exchange Resources are also currently online. We have a successful verified Exchange Cluster failover.

Moving the CMS via the EMS is not the only way to move a CMS. Ever since Exchange Server 2007 SP1 was released, the ability to move a CMS to another node was added into the Exchange Management Console (EMC). So let’s go check out this command and move the CMS back over to NodeA, but this time, by using the EMC (Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Console). Then Expand Server Configuration > Mailbox > Choose Managed Clustered Mailbox Server from the Action Pane.

Select the option “Move the clustered mailbox server to another node.” Select Next to Continue.

Select NodeA as your Target Machine and set the Move comment to whatever you like. Select Next to Continue.

Review the Configuration Summary. Once satisfied, Choose Move to Continue.

Once again, after executing this move, go into the Failover Cluster Management MMC. Expand our Cluster > Services and Applications > CMS (EXServer01). As we can see, the current owner is NodeA which means the move via the EMC was successful. All the “Other Resources” which are the Exchange Resources are also currently online. We have a successful verified Exchange Cluster failover.

Summary

Well folks, that is all for Part 4 of this article and concludes this article series. To recap on what was included in Part 4 of this article series, we first started off recapping what was included in Part 1, Part 2, and Part 3 of this article and what the goal of this lab is for. It is to showcase Server 2008’s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 Failover Clustering. In Part 2, we left off at the final stages of disk preparation. All of the shared disks were successfully portioned, formatted, and named. In Part 3, we formed the cluster, beginning with Node A followed by Node B. We then proceeded with configuring the cluster networks, quorum, and validated our failover cluster worked.

In Part 4, we installed the Exchange 2007 Active Clustered Mailbox role and the Passive Clustered Mailbox role. We then performed management on our Clustered Mailbox Server (CMS) by showing how we can move the CMS via the Exchange Management Shell (EMS) as well as using the Exchange Management Console (EMC).

I hope these articles will help you out on your endeavor to installing Exchange 2007 on Windows Server 2008. Thank you for viewing.

Share

Next »