Microsoft Aurora Beta Generates as Many Questions as Answers

Aurora is based on the Windows Server 2008 R2 platform, which means Aurora must be installed on 64-bit-capable hardware. At a minimum, Aurora also requires 2GB of memory and a single 160GB hard drive, although I tested with 4GB RAM and three virtual disks of differing sizes installed inside Hyper-V running on a Windows Server 2008 SP2 system.

Managing Aurora from the server desktop would be a standard Windows Server administrative experience, but the desktop wallpaper on the server makes it clear Aurora is not meant to be managed that way. Instead, day-to-day management is performed via the Dashboard built into the LaunchPad application running on a client workstation. So while I had to use the familiar Server Manager to add a DHCP server to my test network (DHCP is not installed by default), I consigned all my other administrative tasks to Dashboard from a Windows 7 Enterprise workstation.

From the Dashboard, an administrator can quickly see the status of managed PCs in the domain. I could see what machines are currently online, whether they have been backed up successfully, as well as if any pending alerts (categorized by severity) have been reported to the server. Reported alerts include systems that require important patches and those that lack up-to-date security software.

I easily could configure user accounts from the Dashboard, setting the user’s privilege level (standard or Administrator) and the folders to which they have access. I could also easily reset passwords, define what shares a user can access or the user’s access levels to computers and data resources when they are on the road. 

Like Windows Home Server, Aurora uses Microsoft’s Drive Extender technology to manage hard drives on the server. When adding a disk to the server, I could select whether to add the new storage to the default storage pool for greater aggregate capacity (which opens up the option to enable file duplication for critical folders or share). I could also instead choose to define a new disk as a backup drive, which can be removed and rotated to an offsite location for disaster recovery purposes.  

Storage may get consumed rapidly within Aurora, as each managed workstation is backed up daily by default. However, Microsoft claims Aurora goes about this smartly, backing up only data not previously archived –and accounts for like data found on multiple computers in the network and only saving it once.  Aurora also makes it fairly painless to recover data from a backup:  I was able to recover a file unchanged for about a week from the previous day’s backup within seconds.

Connecting clients to the Aurora domain is quite simple: A user simply needs to browse to http://servername/connect; run the Connect application found on the page (which does require .NET 4 Client Profile to be installed on the client); then log in with their network credentials. After a reboot, the Connect application then asks the user whether they would like to migrate their files and settings from the local profile to the network profile and whether the PC should be woken from sleep or hibernate state to perform scheduled backups.

In my tests, I connected three client computers: A 32-bit Windows 7 Enterprise virtual machine, Windows XP Professional with service pack 3 laptop, and a MacBook Pro running Snow Leopard. Aurora also supports clients running Vista.

Aurora allows users working remotely to easily access their data as well, through RWA (Remote Web Access). Assuming the right holes have been punched in the perimeter firewall, a remote user can use their network credentials to log into a prebuilt, secured Webpage on the server that provides access to those shared folders the user has the rights to see. 

Also through RWA, Aurora makes it simple for a remote user to access their in-office computer via a Web browser. The administrator controls a list of which PCs each remote user can access. Given the right permissions, Aurora brokers a Remote Desktop session between the client browser and the desktop computer in the protected network, theoretically allowing a user to access their work machine from anywhere, provided the target machine is powered up.

I say “theoretically” because I couldn’t actually get it to work in my tests. When setting up RWA on my Aurora server, the wizard asked for a trusted certificate for my external domain. I didn’t have one for my test domain, so I could not complete RWA setup. Throughout my testing, the only noticeable impact of this shortcoming was that Remote Desktop requests could not complete, as the remote client requires a trusted certificate to validate the RDP session. For a full evaluation of Aurora’s capabilities, testers will need to provide such a certificate.

From what I’ve seen so far, the Mac integration unsurprisingly doesn’t offer some the features available for Windows systems. Mac users get their own LaunchPad, with easy access to shared folders and to the Remote Web Access site, as well as backup functionality (which I didn’t test). On the server side, the Mac appears in Active Directory/Computers. Mac users do not get access to a Dashboard, so Aurora management needs to be done from Windows. 

According to Leworthy, Mac is considered a first-level client for support, and the feature set will include LaunchPad, backup support through Time Machine and centralized alerting. However, much of the functionality is still to come later in the beta process.