So now that I have a day or two to play (and need it up already!), I decided to start installing my Essential Business Server environment today. This is not my first kick at this can (I have installed eight or nine previous iterations in either beta or RTM Escrow) so I know there are a number of challenges that I can run into. I am going to diary the entire process from soup to nuts, and hopefully help you avoid some potential stumbling blocks.
Diagram 1: Physical Hardware
The first thing I should call out is my environment. The Physical Hardware diagram is the layout of the devices that I have to contend with. In the grand scheme of things it is an extremely simple layout with fewer devices than an average EBS environment would have. Nevertheless because I wanted to implement the network properly, I still took the time to plan things out.
The Network Plan diagram shows the relevant portion of the new network infrastructure. All of the EBS servers are virtualized within the MDG-Server box. I want to remind you at this point that this EBS network is essentially supporting a single user; For a production network I do NOT recommend virtualizing the three servers in a single box; one of the disadvantages of housing all servers in a single box is that, like with Windows Small Business Server (SBS), you have a single point of failure (SPF) – if your hardware goes down (and even the best servers are prone to do so) so does your entire network. I have known businesses running SBS on the best servers that were brought down by a defective fan.
Diagram 2: Network plan
I give my virtual machines domain names that start with v- so that should my organization grow I will still be able to easily tell which machines are physical and which are virtual. As well I decide to switch to a Class-B address design for the internal network – the connection between the Internet router and the Security Server will keep their Class C addresses. My reasons for this are because eventually I will add a virtual SBS box for demonstrations, and the different addressing will be easier to distinguish. Remember that this is not a scenario that is licensed for production use, and my SBS box will remain completely segregated from the network. I am leaving my physical server on the external address range because I still want to be able to log on remotely using Remote Desktop directly to that box, and not to the EBS infrastructure (which I can still access remotely using Remote Web Workplace (RWW), or by logging onto the parent partition and then accessing the Hyper-V Manager.
A New Error…
I have installed Windows in its various incarnations literally thousands of times without exaggerating. This is the first time that I have ever gotten a warning (when selecting the volume to install to) that Windows requires a system volume on the partition to install. I got a warning, then a STOP error. Weird, and it happened on both the Management and Messaging systems (for those of you who thought I wrote sequentially without going back). The solution is to create a new volume on the Un-partitioned space before proceeding. I do this for both the C and D drives… I don’t know why. The EBS Installation will (when selecting the Data store) give us the option of opening the Drive Management tool to create that partition when the time comes.
EBS Preparation & Planning Wizards
On the parent partition I ran the EBS Preparation Wizard and then the EBS Planning Tool – I was not joining EBS to an existing Active Directory infrastructure, so I could run this from anywhere. These two wizards (on disk 1 of EBS) must be run prior to deploying your EBS infrastructure, and they make sense – they make us think about the questions we might otherwise forget. The wizards create an XML file called PlanningWizardData.xml which is saved to your Documents folder, and can then be copied to a USB key to be imported into the EBS installation process. The problem is if you are installing to a new virtual machine you can’t simply plug in a USB key. Here is my workaround for that problem:
- Store the data on the parent partition;
- Before starting the virtual Management Server add a second NIC to it, and configure it on the same network as your parent partition;
- After the operating system has installed and the Management Server Installation prompts you for the file:
- Press F10 to temporarily break out of the installation process into a Command Prompt window;
- Press Ctrl-Alt-Del and set a password;
- From the Command Prompt window run explorer.exe;
- Create a new directory in the C drive, and share it;
- (From the parent partition) navigate to the share on the Management Server (\\172.16.0.10\<sharename>) and authenticate with Administrator and the password you set;
- Copy the file PlanningWizardData.xml from the parent to the share;
- (From the child partition) reset the Administrator password to <blank>; and
- Exit all windows except the EBS Management Server Installation.
- Navigate to the directory where the file was and select PlanningWizardData.xml.
The Management Server will take quite some time to install – it is creating a domain, installing System Center Essentials (SCE), and other other important tasks. Plan from start to finish two hours for the Management Server. If you want to save a little time you can kick off the deployment of the OS for the Security Server; you can’t install the EBS components, but you can get a head start here.
So once you see the Continue Installation screen in Management Server Installation you
can proceed with the Security Server Installation. As you can see on the screen shot the EBS installation process gives you a lot of visual feedback… in a very nice ‘graphical progress bar’ we see each step, and the ‘Good job, boy!’ Green as I have taken to calling it. You should have seen screens like this in the Preparation and Planning Wizards as well.
My security server – the only one with a single hard disk, though again not the recommended setting – has multiple NICs… one connected to my Internal network (which is not bound to a physical network interface in the parent server) with a Class B address, and one connected to my External network (bound to the NIC that connects to the physical router) with a Class C address. For some reason both of them got addresses from the Management Server’s DHCP Server, so both had Class B addresses. In Hyper-V I opened the settings for the Security Server, disconnected the External adapter; I was then able to distinguish and select the Internal NIC in the setup process. I then reconnected the (virtual) external NIC and continued without incident.
The Security Server Installation rechecks the environment, and if you haven’t disconnected anything in the process it should return a bunch of ‘Good job, boy!’ Green check marks. It reboots several times during the configuration – domain joining and all that rot – and then asks you to confirm the network addresses you will be using.
Because the security server is the first one on my network that will be ‘hot’ – externally facing – I am always careful to allow it to download and install security and critical updates right away. You really should do this for all three servers, but Security is the first point of contact.
It will reboot on its own of course… several times at this point. if you did kick off the Messaging Server deployment then you should wait until prompted by the Security Server before continuing with that server’s installation.
I just noticed one Update Failed message on the Security Server. It is for Microsoft Silverlight, an important update certainly on Vista or even server workstations, but not for the headless security server on EBS. I will not try to go back and remedy that one.
Once my Security Server is done I get my ‘Good job, boy!’ Green screen, and go right on to my Messaging server. Historically this is the one that I have had the most issues with… some having to do with settings, one or two because of ‘beta bugs’ and a plethora caused by environmental factors – Active Directory restrictions and such. In the Hyper-V machine settings I remembered to uncheck the ‘Time synchronization’ in the Integration Services set… I have spoken with people who say that this should not be an issue and I agree, but it always has been for me, and frankly I am bored with dealing with it.
Once you have told the Messaging Server the domain name and password you cannot just walk away… Once it checks and then joins the domain it will ask for more interaction… After the Domain Join is complete it will check the environment, including DNS and Exchange pre-requisites, then ask you IP Address information, and before you press GO on the actual installation you can (as with the other servers) save your Server Configuration file, which I always do. From there calculate about 90 minutes that it will work without you.
I got my ldifde.exe error again… the one that I blogged about recently. It is strange because I do NOT have another domain controller running – I was careful to take my SBS box off-line (read: OFF) before going ahead. I will try the same fix (disconnecting the external NIC on the Security Server) and see if that works…
The problem with this particular error is it can take up to half an hour to materialize, all the while I am waiting patiently. As it happens I know that this fix did not work, because if it had the progress bar would have moved… even a little, slowly. Once it does crash, I move on to my next possible mitigation – switching the (internal) virtual network to a private virtual network. If it doesn’t work I have another half an hour to consider what to try next.
After the third failure I decided that tweaking it might not be enough, and that it might actually need a kick. I restarted the Messaging Server installation from scratch – wiped the partitions and literally started from zero. It seems to have worked, because for the first time the progress bar on the Exchange Server Installation line is moving quite nicely… slow, but steady.
Once the Messaging Server Installation is done (and gives us one more ‘Good Boy!’ green mark) we go back to our Management Server to continue with the Guided Configuration and Migration Tasks. From here on in the Management server is where we will spend most of our time, not only during the Installation process but for the life of our servers. The Guided Configuration and Migration Tasks list is essentially a checklist that takes you from zero to production environment; some of the tasks you are forced to do (Tasks 1, 2, & 3 are Install the Management Server, Install the Security Server, and Install the Messaging Server). Some are informational (i.e.: Migrate DNS), and some are wizard-driven tasks that once completed can be marked as done. Each task will have an estimated time commitment (Management Server being the longest at 2.5 hours). Of course these are estimates based on best-case scenarios, and do not account for two hour delays in the Messaging Server installation due to FSMO issues, Time Synchronization, or intermittent network issues, all of which are issues that I have encountered along the way.
Most of the tasks are important for a production server, but for my purposes they are unnecessary. I do not have multiple
sites, I don’t have a SAN, and (at least for the time being) I am not publishing any web sites that are not pre-configured. I do decide to let EBS manage my DHCP Server for me, which involves a number of steps:
- Verify the DHCP scope in the EBS Management server;
- Disable the DHCP service in my DLink router;
- (Because I am working in a virtual environment) bind my virtual Internal network to a second physical network adapter in my server that is attached to my wireless router.
The rest are tasks that you should pay close attention to, but I am not going to discuss because they are as straightforward as they are different on each network. All told, including the installation of SharePoint on my Management Server, I probably spent nine hours installing my EBS environment. I wish you luck with yours, and look forward to hearing your stories!