Congratulations! Your server should be all ready to be promoted to the first Domain Controller, thus creating your network domain!
To start, go to that "Initial Server Configuration" window and choose "Add Role". This time, select "Active Directory Domain Services".
It will give you some good general information and probably tell you there are some .net frameworks you need to install. Let it do so. Now what it's actually doing is kind of installing the installation files for Active Directory...it's not actually setting up the domain yet. One of those pieces of information it gave you was that once this is done, we'll have to run dcpromo.exe.
So, once that wizard starts, click start and type in "dcpromo" without the quotes, then hit Enter.
Now it ask you what domain you want to create (note that with Foundation edition, you can't make it a sub-domain - it has to be the root of your domain), then it will be using DNS to go out and find out who is "in charge" of the domain. Since you've configured it to use itself as the DNS server to ask, and you've also told it to respond to any requests for information about your domain name with information pointing to itself, it will get the answer back, "I am!". At that point, it allows you to create the domain and you're off and running. There are a few more questions it will ask you (passwords, etc), but you should be able to walk through the wizard fairly easily. Once it's done, it will naturally require a restart, after which your domain has been created.
Friday, November 19, 2010
First role: DNS
For starters, you should probably review the DNS discussion I had in the Preparation section...I'm going to be a little light on explanation here. But this is how to set up your server to run DNS in order to later run Active Directory (that is, be a Domain Controller).
First, you need to give your server a static IP address - click the "Configure Networking" link in the "Initial Server Configuration" window and a new screen will open up with all your network cards in it. Right-click your NIC and choose "Properties". Now highlight the Internet Protocol Version 4 (TCP/IP v4) item and click the "Properties" button. Fill in your static IP address, subnet mask and default gateway, then point the primary DNS server to the same address as your static IP address with no secondary DNS server.
If you try to go to any websites, you'll probably notice that you can't seem to get there - all the domains cannot be found. No worries, we're about to fix that.
In the "Initial Server Configuration" window, click "Add Role". Read through the first window, then you can probably check "Don't show this again" and continue. The role you want to add first is "DNS Server". Once that's done, your browser will be able to find all your websites again (but seriously, don't make it a habit of surfing on your server).
Now, click Start, expand "Administrative Tools" and open "DNS"
At the top of the tree on the left side, you'll see your server. Expand that (if it's not already) and you'll see, among other items, "Forward Lookup". Highlight that, then right-click it and choose "New Zone".
In the wizard that opens, it's first going to ask for the type of zone. We're going to set up a Primary Zone (that is, the "root" of your domain). When it asks for the zone itself, give it the same domain name as you'll use for your network, including .com or .local or whatever. It will prompt you to name the new file for storing the configuration, the default name should be fine.
Now it will prompt you if you want to allow dynamic updates or not. This can be a nice feature if you want it, but it's totally optional. If you allow dynamic updates, then whenever one of the computers on your network gets assigned an IP address, it will log that address in to your DNS server automatically. That way, if your domain is companyname.com and Bob's computer is named "bob", you know that, from within your network, you'll always be able to get to his computer by using the address "bob.companyname.com".
The wizard will warn you that there's a security risk in allowing both secure and non-secure dynamic updates, but we'll fix that once we're running a real domain, so just ignore the warning for now and allow the updates. Click "Finish" to close the wizard.
Great. Now when you go to create your domain, your server will be asking itself for permission, which it will grant. You've just nipped the biggest headache with domains in the bud!
Now, if you've read my "Ahead-of-time Preparations" entry about DNS Configuration, you know that if your website and/or e-mail addresses are the same name as your network domain (and the DNS zone you just set up), you're the only person in the world who can't communicate with those servers. Ironic, huh? Fortunately, it's an easy fix.
You need to get the DNS entries on the "real" nameserver for that public domain, and copy them into your private DNS server configuration. The big ones to look for are, of course, www and any MX-type records (which are the e-mail servers).
You don't have to copy any SOA records, but all the "A" type records, "CNAME" type records (www should be one of these) and "MX" type records are going to be the important records to copy. Note that, when setting records on the root of the domain itself (mostly the "A" type records), you just leave the "Name" field blank.
First, you need to give your server a static IP address - click the "Configure Networking" link in the "Initial Server Configuration" window and a new screen will open up with all your network cards in it. Right-click your NIC and choose "Properties". Now highlight the Internet Protocol Version 4 (TCP/IP v4) item and click the "Properties" button. Fill in your static IP address, subnet mask and default gateway, then point the primary DNS server to the same address as your static IP address with no secondary DNS server.
If you try to go to any websites, you'll probably notice that you can't seem to get there - all the domains cannot be found. No worries, we're about to fix that.
In the "Initial Server Configuration" window, click "Add Role". Read through the first window, then you can probably check "Don't show this again" and continue. The role you want to add first is "DNS Server". Once that's done, your browser will be able to find all your websites again (but seriously, don't make it a habit of surfing on your server).
Now, click Start, expand "Administrative Tools" and open "DNS"
At the top of the tree on the left side, you'll see your server. Expand that (if it's not already) and you'll see, among other items, "Forward Lookup". Highlight that, then right-click it and choose "New Zone".
In the wizard that opens, it's first going to ask for the type of zone. We're going to set up a Primary Zone (that is, the "root" of your domain). When it asks for the zone itself, give it the same domain name as you'll use for your network, including .com or .local or whatever. It will prompt you to name the new file for storing the configuration, the default name should be fine.
Now it will prompt you if you want to allow dynamic updates or not. This can be a nice feature if you want it, but it's totally optional. If you allow dynamic updates, then whenever one of the computers on your network gets assigned an IP address, it will log that address in to your DNS server automatically. That way, if your domain is companyname.com and Bob's computer is named "bob", you know that, from within your network, you'll always be able to get to his computer by using the address "bob.companyname.com".
The wizard will warn you that there's a security risk in allowing both secure and non-secure dynamic updates, but we'll fix that once we're running a real domain, so just ignore the warning for now and allow the updates. Click "Finish" to close the wizard.
Great. Now when you go to create your domain, your server will be asking itself for permission, which it will grant. You've just nipped the biggest headache with domains in the bud!
Now, if you've read my "Ahead-of-time Preparations" entry about DNS Configuration, you know that if your website and/or e-mail addresses are the same name as your network domain (and the DNS zone you just set up), you're the only person in the world who can't communicate with those servers. Ironic, huh? Fortunately, it's an easy fix.
You need to get the DNS entries on the "real" nameserver for that public domain, and copy them into your private DNS server configuration. The big ones to look for are, of course, www and any MX-type records (which are the e-mail servers).
You don't have to copy any SOA records, but all the "A" type records, "CNAME" type records (www should be one of these) and "MX" type records are going to be the important records to copy. Note that, when setting records on the root of the domain itself (mostly the "A" type records), you just leave the "Name" field blank.
Begin configuration
Each time you boot, a window will be waiting for you, called "Initial Configuration Tasks". Start at the top:
- Windows should already be activated, so you can skip that one.
- You probably need to change your time zone...this is really important for computers on a domain, because they need to make sure they're getting current information.
- It's a good idea to change the computer name to whatever you're going to call it - something like DC01 (for Domain Controller). This will require a restart.
- Now, enable Automatic Updates, then check for and install any critical updates. I also installed all the optional updates that weren't a "best-practice checklist"...I'll come back to these later. This will likely require a restart as well.
- Windows should already be activated, so you can skip that one.
- You probably need to change your time zone...this is really important for computers on a domain, because they need to make sure they're getting current information.
- It's a good idea to change the computer name to whatever you're going to call it - something like DC01 (for Domain Controller). This will require a restart.
- Now, enable Automatic Updates, then check for and install any critical updates. I also installed all the optional updates that weren't a "best-practice checklist"...I'll come back to these later. This will likely require a restart as well.
Getting to the desktop
Finally, you're ready to boot up your new server!
Make sure you've got a keyboard, mouse, monitor cable and network cable plugged in.
Start the server and wait through the boot screens and Vista-era black-screen-with-progress-bar splash (why it doesn't use the Windows 7-era splash?), and the OOBE (out-of-box-experience) part of setup will start. Fortunately, this is very short and easy:
Once it gets to a login screen, click the "Administrator" username and it will tell you that you must change your password. Type your chosen password twice, and click the arrow to get in to your new desktop. That was easy, wasn't it!!?
As a side note, I went into my BIOS and disabled PXE boot because it was adding unnecessary time to my boot sequence. Again, this is on a Dell PowerEdge T110. If you don't know what PXE boot is, you probably don't need it, especially on a server preinstalled with Foundation.
Make sure you've got a keyboard, mouse, monitor cable and network cable plugged in.
Start the server and wait through the boot screens and Vista-era black-screen-with-progress-bar splash (why it doesn't use the Windows 7-era splash?), and the OOBE (out-of-box-experience) part of setup will start. Fortunately, this is very short and easy:
- Accept the EULA(s)
Once it gets to a login screen, click the "Administrator" username and it will tell you that you must change your password. Type your chosen password twice, and click the arrow to get in to your new desktop. That was easy, wasn't it!!?
As a side note, I went into my BIOS and disabled PXE boot because it was adding unnecessary time to my boot sequence. Again, this is on a Dell PowerEdge T110. If you don't know what PXE boot is, you probably don't need it, especially on a server preinstalled with Foundation.
DNS Setup
Many of the services we'll be setting up work best in a "domain" environment, which is why I'm going to be making my new servers Domain Controllers, among other things. A domain NAME is something like "google.com", and you can actually buy a public name like that ($10/year fee at most places), but you don't have to. If you buy a public domain name, you can not only use it to set up a domain for your computers to be managed by your servers, but also to have a website and e-mail, which are the only things most people think domains are for.
BUT!!! If you already have a website and/or e-mail solution (maybe gmail and a free blog, for instance), there's no need to actually buy a public domain address just to run your network - you can call it whatever you want, and don't even need a dot-anything at the end of the name (though many times in this case, I see people actually name the domain something like "domain.local").
Now, no matter what, when you go to create your domain, your first domain controller is going to ask the nearest DNS (Domain Name Service) server for the address of the authoratative server for that domain name - to make sure it's allowed to create that domain. One of the required bits of information when you register a domain name is the address of a name server, which is a DNS server. That DNS server holds the master records that tell other machines what address to translate your domain name to, including the address of the authoratative server. If you've purchased a domain name, it is possible to set your server as the authoratative server for that domain, meaning that anyone asking for an address in your domain will actually be getting the answers from your server, whether they're asking from a machine within your network, or somewhere out in the world. The traffic that could potentially generate might be too much for your servers which, if they're running Foundation, are pretty low-end after all.
It's far better to let your registrar's own name servers handle all the requests from the outside world. But maybe you can see the problem building up...if your servers aren't the authoratative name servers for the domain, how can you get permission to set your servers up as domain controllers? An even bigger problem is if you don't buy the public domain name - if your server starts asking other servers who is in charge of that non-existent domain name, it's not going to get any answers.
The solution for both problems is the same...you "trick" your servers. What you actually do is set your server up as a DNS server, just for handling requests within your own network, and give it it's own address as the address of the authoratative server. Finally, you tell it to use itself as it's own server to get answers from. That way, when it asks it's DNS server (itself) for the address of the authoratative server, it gets it's own address, and grants itself permission to create a domain.
I know it seems like a security risk that you can just "trick" them in this way, but it's really not. Because the only computers in the world that will be asking your server to translate domain names, are computers which are configured to use your server as their DNS server. Nobody is going to do that, of course, except the computers on your network. So even if you told your computer that it's authoratative for the domain microsoft.com and set up a domain in that name, the only computers that are going to think that your server is microsoft.com, are your own users. Everyone else will get info from the actual microsoft.com name server. The result of that would be that your users would be unable to communicate with the real microsoft.com computers (e-mail, web site, etc), but nobody else would be affected.
One final problem for those of us whose network domain uses the same domain name as your website and/or e-mail domain. As I said, all the computers in your network will be using your server to translate DNS addresses rather than the "public" nameservers contained in your domain name registration. So ironically, you end up being the only users in the world who can't get to your own website.
The answer to this one, fortunately, is easy enough: we'll just copy all the DNS records from the public nameservers for your domain onto your own server. That way, they get the same IP Address for the website-hosting computer from within your network as everyone else.
So...all the background is out of the way, so what should you do ahead of time?
BUT!!! If you already have a website and/or e-mail solution (maybe gmail and a free blog, for instance), there's no need to actually buy a public domain address just to run your network - you can call it whatever you want, and don't even need a dot-anything at the end of the name (though many times in this case, I see people actually name the domain something like "domain.local").
Now, no matter what, when you go to create your domain, your first domain controller is going to ask the nearest DNS (Domain Name Service) server for the address of the authoratative server for that domain name - to make sure it's allowed to create that domain. One of the required bits of information when you register a domain name is the address of a name server, which is a DNS server. That DNS server holds the master records that tell other machines what address to translate your domain name to, including the address of the authoratative server. If you've purchased a domain name, it is possible to set your server as the authoratative server for that domain, meaning that anyone asking for an address in your domain will actually be getting the answers from your server, whether they're asking from a machine within your network, or somewhere out in the world. The traffic that could potentially generate might be too much for your servers which, if they're running Foundation, are pretty low-end after all.
It's far better to let your registrar's own name servers handle all the requests from the outside world. But maybe you can see the problem building up...if your servers aren't the authoratative name servers for the domain, how can you get permission to set your servers up as domain controllers? An even bigger problem is if you don't buy the public domain name - if your server starts asking other servers who is in charge of that non-existent domain name, it's not going to get any answers.
The solution for both problems is the same...you "trick" your servers. What you actually do is set your server up as a DNS server, just for handling requests within your own network, and give it it's own address as the address of the authoratative server. Finally, you tell it to use itself as it's own server to get answers from. That way, when it asks it's DNS server (itself) for the address of the authoratative server, it gets it's own address, and grants itself permission to create a domain.
I know it seems like a security risk that you can just "trick" them in this way, but it's really not. Because the only computers in the world that will be asking your server to translate domain names, are computers which are configured to use your server as their DNS server. Nobody is going to do that, of course, except the computers on your network. So even if you told your computer that it's authoratative for the domain microsoft.com and set up a domain in that name, the only computers that are going to think that your server is microsoft.com, are your own users. Everyone else will get info from the actual microsoft.com name server. The result of that would be that your users would be unable to communicate with the real microsoft.com computers (e-mail, web site, etc), but nobody else would be affected.
One final problem for those of us whose network domain uses the same domain name as your website and/or e-mail domain. As I said, all the computers in your network will be using your server to translate DNS addresses rather than the "public" nameservers contained in your domain name registration. So ironically, you end up being the only users in the world who can't get to your own website.
The answer to this one, fortunately, is easy enough: we'll just copy all the DNS records from the public nameservers for your domain onto your own server. That way, they get the same IP Address for the website-hosting computer from within your network as everyone else.
So...all the background is out of the way, so what should you do ahead of time?
- Register your public domain name, if you want to
- I do recommend allowing the registrar to host the public name servers
- If you don't already have e-mail and a website, most of them also offer these services for additional fees. Again, since we're using Foundation server, I recommend out-sourcing these services rather than trying to run them from your server...it's a lot easier, too! Personally, we use the free version of Google Apps which allows up to 50 e-mail addresses/users
- Find out how to get to your DNS listings for your domain name, as we'll need to copy these later
- If you're not going to register a public domain name, make sure that whatever you do decide to name your domain won't block your access to someone else...call it something that will never be a website like "complanyname.local" or just plain "companyname" without a dot-anything.
- The way I have my network set up (and the way I do recommend) is to have a router that serves as both a firewall for my network as well as a DHCP server, assigning IP addresses to any computer within my network that asks. Though you can configure your server to fulfill both these roles (if you have two network cards in your server) it does add a LOT of complexity to your setup. So make sure you've got a router that does both of these things, and that it's configured correctly. If you have multiple offices, you may want one that creates a VPN link between the offices as well...that's how mine is set up.
Wednesday, November 17, 2010
Capturing a disk image
My new servers have arrived! And happily, when I opened the boxes, I found I was mistaken about the lack of installation media in my previous post. However, I figure that it's always better to have too many options rather than too few in situations like this. Also, Dell usually includes a plain (although re-labeled) OS installation DVD (which I really appreciate), then on a separate DVD, includes all the drivers - and typically many more than are actually necessary.
To be sure, I'm glad they do it this way rather than not giving you a "pure" OS installation, but wouldn't it be nice to have an install of just the OS and the drivers your machine actually needs?
Basically, that's what this disk image will be.
So set up the server with a monitor and keyboard, then use a paper clip to open the DVD drive and pop in the WinPE and ImageX disk we made last time. Then push the drive closed again, and start up the computer.
Most computers will check for a bootable CD/DVD and prompt you to, "Press any key to boot from CD/DVD", but to be safe, check the POST screen to see if there's a key you can press to bring up a boot device selection menu. Either way, it should prompt you to press a key: do so, and you'll see a Windows 7-esque boot splash screen, followed finally by a console window over an "Aura" background.
Switch around from drive to drive to make sure you know where everything is. X: is usually a virtual "RAM Disk" with some tools we won't use, and C: usually starts the physical disks. On these servers, C: is a Recovery partition, D: is an empty data partition (I requested my single hard drive have a 80GB partition for the OS, and the rest be a separate, empty partition). E:, when I asked for a directory of the contents, shows me the expected Windows, Program Files and Program Files (x86) directories, along with other directories such as "Dell", "Drivers" and "Hotfixes". Bringing up F: then, showed me the contents of my actual bootable CD, including ImageX. Note the drive letters do not relate at all to the drive letters they will actually be from within Windows.
So, once you find your system partition (E: in my case) and your optical drive (F: in my case), switch to the optical drive, then run ImageX. For instance, here's the command I used:
"Foundation", " Foundation OOBE" and "Dell Windows Server 2008 R2 Foundation (Pre-OOBE)" are all strings you can modify to help you identify the desired disk image if you ever go to restore it. They represent the Edition, the Name of the image, and a description of the image, respectively.
On my servers, it took about 10 minutes, and the image file is about 2.3 GB (2.45 billion bytes)
Now eject the CD and "exit" WinPE. Later on, you can, of course, burn the WIM file you created in the root of the system drive to a DVD if you want to get it off the physical drive (always a good idea).
To be sure, I'm glad they do it this way rather than not giving you a "pure" OS installation, but wouldn't it be nice to have an install of just the OS and the drivers your machine actually needs?
Basically, that's what this disk image will be.
So set up the server with a monitor and keyboard, then use a paper clip to open the DVD drive and pop in the WinPE and ImageX disk we made last time. Then push the drive closed again, and start up the computer.
Most computers will check for a bootable CD/DVD and prompt you to, "Press any key to boot from CD/DVD", but to be safe, check the POST screen to see if there's a key you can press to bring up a boot device selection menu. Either way, it should prompt you to press a key: do so, and you'll see a Windows 7-esque boot splash screen, followed finally by a console window over an "Aura" background.
Switch around from drive to drive to make sure you know where everything is. X: is usually a virtual "RAM Disk" with some tools we won't use, and C: usually starts the physical disks. On these servers, C: is a Recovery partition, D: is an empty data partition (I requested my single hard drive have a 80GB partition for the OS, and the rest be a separate, empty partition). E:, when I asked for a directory of the contents, shows me the expected Windows, Program Files and Program Files (x86) directories, along with other directories such as "Dell", "Drivers" and "Hotfixes". Bringing up F: then, showed me the contents of my actual bootable CD, including ImageX. Note the drive letters do not relate at all to the drive letters they will actually be from within Windows.
So, once you find your system partition (E: in my case) and your optical drive (F: in my case), switch to the optical drive, then run ImageX. For instance, here's the command I used:
imagex /compress maximum /check /flags "Foundation" /capture e: e:\OOBE.wim " Foundation OOBE" "Dell Windows Server 2008 R2 Foundation (Pre-OOBE)""Foundation", " Foundation OOBE" and "Dell Windows Server 2008 R2 Foundation (Pre-OOBE)" are all strings you can modify to help you identify the desired disk image if you ever go to restore it. They represent the Edition, the Name of the image, and a description of the image, respectively.
On my servers, it took about 10 minutes, and the image file is about 2.3 GB (2.45 billion bytes)
Now eject the CD and "exit" WinPE. Later on, you can, of course, burn the WIM file you created in the root of the system drive to a DVD if you want to get it off the physical drive (always a good idea).
Tuesday, November 16, 2010
WinPE and ImageX
The fact that Foundation edition is OEM-only has a few implications...among these, the facts that you can neither install a trial version to test it out before investing, and that it's apparently not possible to obtain installation media, even once you do buy it.
Now, I've had great success with Windows 7, but I'm not comfortable assuming that I'll never need to reinstall these servers, especially now that I can "seed" replication groups with good data.
So before the servers arrive, I've gone through the process of re-familiarizing myself with various parts of the Windows AIK (Automated Installation Kit).
My primary goal is to get a bootable CD that I can boot the servers from ON FIRST BOOT and create an image of C:\, still prepped in the OOBE. That way, if (when) I do need to reinstall in the future, I can wipe out the C:\ and push this image back onto it, allowing me to start over with initial setup again. Essentially, I'm creating my own installation media, though I won't be including it in the normal setup routine.
The tool Microsoft has developed for capturing a disk image is called ImageX, and the bootable CD environment it will run in is called WinPE. Here's how to make the disk you need:
Now, I've had great success with Windows 7, but I'm not comfortable assuming that I'll never need to reinstall these servers, especially now that I can "seed" replication groups with good data.
So before the servers arrive, I've gone through the process of re-familiarizing myself with various parts of the Windows AIK (Automated Installation Kit).
My primary goal is to get a bootable CD that I can boot the servers from ON FIRST BOOT and create an image of C:\, still prepped in the OOBE. That way, if (when) I do need to reinstall in the future, I can wipe out the C:\ and push this image back onto it, allowing me to start over with initial setup again. Essentially, I'm creating my own installation media, though I won't be including it in the normal setup routine.
The tool Microsoft has developed for capturing a disk image is called ImageX, and the bootable CD environment it will run in is called WinPE. Here's how to make the disk you need:
- Install WAIK
- Download installation DVD from (currently) http://www.microsoft.com/downloads/en/details.aspx?FamilyID=696dd665-9f76-4177-a811-39c26d3b3b34
- It's an iso file
- This is the version that was updated 11/15/2010
- Create the installation disk
- On Windows 7, you don't need a separate ISO burner
- Can also just mount it as a disk (find tool)
- Install WAIK by choosing "Windows AIK Setup" from the disk menu
- Now you can unmount or eject the WAIK disk
- Create a WinPE Disk (documentation)
- Start->All Programs->Microsoft Windows AIK->Deployment Tools Command Prompt
- copype.cmd amd64 c:\winpe_x64
- Windows Server 2008 R2 is 64-bit only
- copy c:\winpe_x64\winpe.wim c:\winpe_x64\ISO\sources\boot.wim
- copy "c:\Program Files\Windows AIK\Tools\amd64\imagex.exe" c:\winpe_x64\iso
- oscdimg -n -bC:\winpe_x64\etfsboot.com C:\winpe_x64\ISO C:\winpe_x64\winpe_x64.iso
- exit
- Burn the CD
- File is at c:\winpe_x64\winpe_x64.iso
- On Windows 7, you don't need a separate ISO burner
- Label it "WinPE and ImageX"
Why I'm doing this
As the first post in this blog, I thought I'd explain what I'm doing with it and what I intend for this to grow into.
First, about our company:
We're a pretty small company (in the range of 10 employees, though a few positions come and go from time to time), but we have locations in two different cities. It's an architecture firm, so we need lots of storage space, and our work can be pretty graphics-intensive.
Five years ago, we finally got our first real servers, replacing a haphazard system of locally-stored files and networked computers in a workgroup. I'd worked with DFS during college (since I enjoy this stuff as a hobby, I assisted the network administrator for the College of Architecture for a few semesters), so I knew that was the best way to provide everyone with a single place for all our files, and to ensure that everyone in both offices had the same data.
Alas, we purchased our servers about 6 months before Server 2003 R2 was released, and the original version of Server 2003 was missing some features I would come to mourn not having. Highest among these was the ability to "seed" a replication group...when it came time to reformat the servers and start over (remember, 2003 was based on XP-era technology), I had to actually erase all our files and re-sync them afresh from the other server once it was back up. Usually, that's but an annoyance, but in this case the files were synched over a relatively slow WAN connection, and it would take months to fully propogate, during which time the office with the reinstalled server would be working off the remote server...very slowly. The only time I actually did this, I ended up physically taking the first server to the second office for a weekend to let it sync locally, then brought it back up and plugged it back in at it's own office once that was done. Yikes.
There are a number of issues that have come up besides that ever-present cloud over me, but finally we've reached the point where the servers have stopped syncing our data with each other at all, so it's time to replace them.
I've evaluated a number of options - SANs (Drobo), cloud computing (Live, Azure), thin clients and alternate Server editions (SBS), etc to try and keep costs down as much as possible in this pretty tight time, but I kept coming back to on-site full-meal-deal Windows Server boxes. The glimmer of hope I had was that the far less expensive Foundation edition might meet my needs: Active Directory and DFS. Not much good documentation exists for Foundation, but I've spent several weeks working with a very helpful team over at Dell and finally came to the conclusion that it will, in fact, meet my needs - my total bill thus coming to about 1/3 what it otherwise would have.
There aren't many businesses that fit in the crosshairs of the Foundation demographic (fewer than 15 users, but with needs of a real Server operating system), which is doubtlessly why there's so little good information on it specifically, so I'm hoping that by documenting my "travels" through this obscure system, there might be someone else who is helped by my experience, in addition to being a good start to my documentation of our new network infrastructure.
Tomorrow my new servers arrive, and thus begins the adventure. Hopefully I'll emerge victorious on the other side.
First, about our company:
We're a pretty small company (in the range of 10 employees, though a few positions come and go from time to time), but we have locations in two different cities. It's an architecture firm, so we need lots of storage space, and our work can be pretty graphics-intensive.
Five years ago, we finally got our first real servers, replacing a haphazard system of locally-stored files and networked computers in a workgroup. I'd worked with DFS during college (since I enjoy this stuff as a hobby, I assisted the network administrator for the College of Architecture for a few semesters), so I knew that was the best way to provide everyone with a single place for all our files, and to ensure that everyone in both offices had the same data.
Alas, we purchased our servers about 6 months before Server 2003 R2 was released, and the original version of Server 2003 was missing some features I would come to mourn not having. Highest among these was the ability to "seed" a replication group...when it came time to reformat the servers and start over (remember, 2003 was based on XP-era technology), I had to actually erase all our files and re-sync them afresh from the other server once it was back up. Usually, that's but an annoyance, but in this case the files were synched over a relatively slow WAN connection, and it would take months to fully propogate, during which time the office with the reinstalled server would be working off the remote server...very slowly. The only time I actually did this, I ended up physically taking the first server to the second office for a weekend to let it sync locally, then brought it back up and plugged it back in at it's own office once that was done. Yikes.
There are a number of issues that have come up besides that ever-present cloud over me, but finally we've reached the point where the servers have stopped syncing our data with each other at all, so it's time to replace them.
I've evaluated a number of options - SANs (Drobo), cloud computing (Live, Azure), thin clients and alternate Server editions (SBS), etc to try and keep costs down as much as possible in this pretty tight time, but I kept coming back to on-site full-meal-deal Windows Server boxes. The glimmer of hope I had was that the far less expensive Foundation edition might meet my needs: Active Directory and DFS. Not much good documentation exists for Foundation, but I've spent several weeks working with a very helpful team over at Dell and finally came to the conclusion that it will, in fact, meet my needs - my total bill thus coming to about 1/3 what it otherwise would have.
There aren't many businesses that fit in the crosshairs of the Foundation demographic (fewer than 15 users, but with needs of a real Server operating system), which is doubtlessly why there's so little good information on it specifically, so I'm hoping that by documenting my "travels" through this obscure system, there might be someone else who is helped by my experience, in addition to being a good start to my documentation of our new network infrastructure.
Tomorrow my new servers arrive, and thus begins the adventure. Hopefully I'll emerge victorious on the other side.
Subscribe to:
Comments (Atom)