Meet Aurora (1 of ??)Author: q | Filed under: Aurora
Now that the public beta of Aurora is out and in the wild, we can finally talk turkey about the product and what it does and doesn”t do. To that end, I”m starting a series of posts to introduce people to Aurora who might not otherwise be able to look at the product. My reasons for doing this (given that there are a lot of other folks who are also blogging/writing about the product) are multifold. First, back in the SBS 2008 pre-release days, I got up on my soapbox and told everyone who would listen that they needed to take a long hard look at SBS 2008 because it was significantly different from SBS 2003. Based on the types of issues I”m still helping IT Pros get through with SBS 2008, there are a LOT of people who didn”t do this. Well, Aurora is completely different from anything you”ve seen in the SBS product space before, and as such, there are some misconceptions and false assumptions I hope I can stamp out early on through these posts. Second, there are some things about the defaults in Aurora that I think need to be tweaked that I doubt very seriously will make it into the final product release build, so I”ll be documenting some of those tweaks here as we go through the series. Third, there are some,well,*different* things I”ll be doing with Aurora, and I want to have a place to highlight some of those unusual configurations someplace, especially if a few of these zany ideas make sense to other IT Pros who want to use them in their own deployments. Finally, I think that Aurora is going to be a huge player in the under-25 employee business, and the sooner consultants and businesses learn about what it can (and cannot!) do, the better!
So, with that introduction, let”s get started. If you haven”t already, I HIGHLY RECOMMEND that you start learning about the product on your own. You can get some overview information from the SBS Blog post from Michael Leworthy. That post includes links to several resources, including an overview video, that make for a good introduction. I”d also recommend, if you haven”t already, that you read the Aurora Beta Announcement on the SBS Blog and go sign up for the beta of the product so you can get your hands on the bits now.
While you”re waiting for the bits to download, let”s take a quick tour of an out-of-the-box basic install of Aurora in a test environment. From the basic desktop screen, you can see that this is NOT your typical SBS.
In fact, if you”ve seen Windows Home Server, it should look really familiar to you (especially if you”ve been in on the Vail beta). That”s because Aurora is built on the same codebase as the next version of Windows Home Server, codenamed Vail. We”ll get more into the similarities in later posts, but for now, let”s mention the one key difference between Vail and Aurora, and that”s Active Directory.
As you”ll see in the above image, when looking at the list of services running on our unmodified Aurora install, there are Active Directory services running on this server. These are set up as part of the Aurora install and are present by default (i.e., you cannot choose whether to install Active Directory or not). Part of the licensing restriction for Aurora is that it must run Active Directory, and it must be the root domain holder for the network (very similar to the licensing restrictions for SBS, and the reason why you cannot have Aurora and SBS in the same domain).
One other key service of Active Directory is DNS, and as you can see in the above shot of the second page of services on Aurora, the DNS server service is installed and running. Again this is done as part of setup and is not configurable. Active Directory relies heavily on DNS, so it”s good to have the service there and pre-configured as part of the setup.
If you look carefully at the list of services in that second screenshot, however, you may notice something missing (if you”re used to the typical SBS installation). That”s right, there”s no DHCP Server service listed. Aurora does not preinstall or preconfigure DHCP services for the network. The default assumption with Aurora is that some other device on your network, perhaps the Internet Router, is providing DHCP for the network. This is one area where I disagree with the default configuration of Aurora out of the box. I firmly believe that DHCP should be installed and running on Aurora so that proper AD information can be handed out to workstations participating in the Aurora network, such as the default internal domain name and the IP address of the Aurora box as the primary DNS server for the workstations. Anyone who has run across domain-joined workstations that do not point to a domain-enbled DNS server knows that the Active DIrectory performance of the workstation leaves a great deal to be desired. Fortunately, the DHCP service can be installed on Aurora, and I have it on good authority that steps for doing so will be included on independent Aurora build docs that are being developed right now.
Next, let”s take a look at the Active Directory environment that is configured with Aurora. Below is a capture of the Active DIrectory Users and Computers console showing the AD defaults for Aurora.
Again, anyone familiar with SBS will notice significant differences in the SBS AD configuration and the Aurora AD configuration. The Aurora AD configuration is the same as what you would get installing Active Directory on a standard Windows Server 2008 box. No custom OUs, user accounts placed in the Users containers, and so on. This isn”t necessarily a bad thing – Foundation Server does the same when AD is installed (not installed by default). But it *is* different from SBS, and that”s something that IT Pros need to be aware of. This configuration has significant impacts on how Group Policy will be applied, but we”ll dive into Group Policy on Aurora in more detail in a later post.
Since we did mention Group Policy, however, let”s take a quick peek at the Group Policy configuration in our out-of-the-box Aurora install:
When you look in the Group Policy Management Console, you”ll see that the only GPOs listed for the domain are the Default Domain Policy and the Default Domain Controllers Policy. That”s it. Again, this is exactly what you”d expect from a traditional Active Directory installation, but NOT from an SBS installation. SBS has used Group Policy heavily in its configuration since SBS 2003, but that is not the case in the default Aurora install.
So in this quick look at Aurora, I hope you”ve seen that Aurora is NOT the “next version of SBS” as some media outlets have claimed that it is. It”s going to be an interesting hybrid of Home Server and Foundation Server, but it is NOT a derivative of the traditional SBS product line. While not all of the details regarding Aurora have been finalized or made public yet (i.e., pricing, licensing, additional restrictions, etc.), I still think that this is going to be a great platform to build on for the 1-20 employee business. I”m already making plans to “upgrade” several of our customers from SBS 2003 to Aurora (and I”ll cover more about how I plan to approach that move from a technology standpoint in later posts in this series) once the product is released, and see the potential of this product with other clients that we haven”t had a good solution for up until now. But as different as this product is, the typical SBS consultant will need to rethink the way they approach ongoing maintenance for this solution, and the best way to devise those plans is to start working with the product NOW to see what you”re really up against. Some of the tools or processes you”ve been using for years simply may not work the same way on Aurora as they do your other supported devices, and you really don”t want to figure that out AFTER you”ve deployed this to a customer.
Bottom line, we”re sold on Aurora, and think you will be, too.