Windows Server 2012 Beta Essentials Post 3: The Client View
In two previous posts, I talked about the installation process for Windows Essentials Server 2012 Beta and some of the configuration process. In this post, I am going to show the same lab environment with configuring a pair of clients, a Windows 7 client and a Windows Server 2008 R2 server.
The Windows 7 Client
I started with the Windows 7 Client. When I set up the server, it configured a local IIS installation with three web sites:
The default, primary web site includes a virtual directory for connecting to the server, like the earlier product incarnations. I was able to connect to it from the Windows 7 client:
I clicked the Download link, and that gave me an EXE to run. Notice underneath the very large Windows link is a much smaller Mac link. I don’t have the ability to test this now (primarily because I can’t easily run an OS X VM), but at some point I hope to be at the office where a Mac Mini sits somewhat abandoned.
Moving on, I received the expected UAC prompt:
Notice it shows as “Downloaded from the Internet”. Out of curiosity, I clicked No, then enabled Intranet settings as I had be prompted to by Internet Explorer:
Then, I emptied the IE cache (to make sure the client really re-downloaded the connector), then clicked the Download link again. This time, UAC shows it as a local file:
I admit I had never tried this before, so I didn’t really know what to expect; this is somewhat interesting I think. Continuing, the Connector searched for the server:
The Getting Started wizard came up at that point:
In this case the client was fully patched with all optionally offered components from Windows Update, so the client had everything the Connector wanted:
That said, notice the Connector is going to install the recent .NET Framework 4.5, which in fact wasn’t even RTM’d until just a couple of weeks ago. Continuing:
While that ran, I went ahead and started the server also, just to keep things moving. I had not done much on the server, so it still had the Internet Explorer Enhanced Security Configuration enabled, causing a warning when connecting to the Connect virtual directory:
That gave an interesting prompt in the Connect site:
Same process, just without the client Aero/desktop experience UI touches.
At this point the client was ready for me, so I left the server going for the time being and went back to the client:
I put in my account credentials for an administrator and was told, basically, “don’t do that!”:
So I said Yes, and used a standard user account:
It would have been nice if the user login dialog made it clear that they would recommend a standard user account, perhaps saying something like “we recommend you do not use an administrator account for connecting…” but at least in this release it doesn’t.
At this point, I hit an error, and retrying didn’t help:
So I decided I’d let the client go for now, and switch back to the server, where I saw something very interesting:
So this was a surprising thing to see – server against server isn’t officially supported, but you can try it. Well, this is all about experimentation and learning, so of course I said “Continue anywhere”. At that point, I was told that I might need to have some server components added, which might require a reboot. I didn’t screen capture that because, well, I clicked “Next” like everyone normally does, so you don’t get to see that dialog here. But would I lie to you about what it said?
So that left the server doing the prerequisite work, so it was a chance to check the client out again. I put on my “normal person” hat again, and rebooted the client, because when in doubt, reboot, right? So I did that, and checked the server in the meantime to see that two automatic services had stopped – Software Protection and Remote Registry. I started them both and went back to the client. I logged back in to the client and restarted the Connector installation. The installation moved past the prerequisite check much quicker this time because there was no work for it to do, and then asked for credentials again. This time, there was a much longer wait, but again, the client couldn’t connect to the server. The troubleshooting link wanted to go online, which didn’t help me any as I had no Internet access. But looking at the server again, the Remote Registry service had stopped again! Software Protection had also, but I didn’t really care about that one. Remote Registry is a much bigger deal – lots of different weird remote connection scenarios fail without it. But still no dice.
So now, I had to figure out what happened there. I was able to ping the server by name through IPv6 but not IPv4, so I added the server as an IPv4 host to the local client HOSTS file. I have to do this with Windows Home Server, so I thought it might help here:
And that’s why I figured out that DHCP actually wasn’t working in the lab, so I had no IPv4 address. What an idiot I was! Well, that was easy to fix – I just gave the client an IPv4 address and ta da, it worked. So then I commented out the HOSTS entry as I shouldn’t have needed it, and ran the Connector yet again. I should point out how interesting it was that IPv6 automatic addressing worked completely to access the server at this point including accessing IIS, downloading the Connector installer, and doing the initial steps to here, all of which shows that IPv6 pretty much “just works” for a lot of stuff in this scenario, but not everything.
This time, things made it slightly further:
So I checked the date/time information and it was fine. But the server showed something more interesting:
Active Directory Certificate Services denied request 7 because The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613). The request was for CN=MIKEBAZ-PC. Additional information: Error Constructing or Publishing Certificate Resubmitted by BLOGDEMO\BLOGDEMOSERVER$.
OK, well, let’s bounce Certificate Services. It is common for a VM save/restore cycle to break CS revocation checks, actually, and restarting AD CS solves it, so I did that.
And look, finally, more progress!
What was really going on here, although it wasn’t completely telling me, was that it was migrating local user profiles for domain user use, much like a tool like Quest Migration Manager’s VMover tool would do. I chose the simplest option of setting up for myself and letting it migrate. Note that I had placed the Connector installer on the desktop at this point, so that would be a way to see if the Desktop migrated correctly. At that point, it was time to reboot:
After the reboot, there was an automatic login, then a prompt for the computer’s description:
This is not that different than the previous product releases. This is also true of the backup wake prompt:
I was then asked about the CEIP:
The user profile was migrated:
There was a quick “configuring the computer” step I didn’t get a picture of, then a download of the full Connector software:
The computer was then “connected” to the server:
In the previous Windows Home Server releases this was a relatively light operation but in this case, it was a domain join operation. It then finalized:
And told me it was done:
I chose not to run the Dashboard at this time. I was logged off as promised, so I logged in with my domain credentials – noticing the machine was indeed now configured to log in to the domain as would be expected:
The login worked, and my Desktop came back correctly, with the new look of the Launchpad showing up:
The three complaints were about lacking virus and spyware protection and not having Windows Update configured, all of which is accurate:
But one interesting thing in the viewer that I didn’t expect was this:
This computer is not connected to the server.
This was a little odd. I clicked Shared Folders in the Connector, and I could connect fine:
So I don’t know what was up with “not connected” message. I’m thinking it’s a beta bug but I don’t know that for sure.
For now, that’s far enough – I’ll come back to it later in the post, but I want to get back to the server and finish it. When I went back, it was waiting for login credentials, which I gave it just like on the client machine. I then had to restart the server:
So I restarted, and again I got the screen for profile configuration:
Notice this time I did not get the “I do not need to migrate..” checkbox. I don’t know if that is because there was only the local Administrator on the server or because it was a server OS – there’s likely a good investigation point there – but in any event I chose just the one account again. The remaining steps were exactly the same as on the client, as you would expect.
That said, something odd next happened. Because the migrated account was Administrator, I couldn’t log in with it, because by default that account is disabled in the domain. It seems there’s a small edge case gap here; the Connector should probably warn about this edge case.
Anyway, the server was joined to the domain when it came up. So let’s look now at backing up a machine. I brought up the Dashboard, and was prompted for credentials:
Why was I prompted for credentials when I’m logged in to a domain account in the domain for the Essentials server? Well, after I entered credentials, I was told I wasn’t an administrator… so that’s why, it wanted administrative credentials. It didn’t say explicitly that’s what it wanted, but of course it makes perfect sense.
I closed the Dashboard because I just wanted to see it came up. What was not available though was Launchpad. It wasn’t in the Start Menu at all:
The executable was there, it just didn’t launch:
I tried Windows 7 Compatibility Mode but no go. So there’s an issue there – can’t run the Launchpad on a server. Doing it is not supported, so it’s not 100% surprising, but in a small business environment I can see it being a nice thing to have.
After seeing that, I launched the Dashboard again, to see if I could manually launch a backup, but I couldn’t, so I’m going to have to let it run long enough at some point to hit the scheduled window and see the backup work.
However, I could go back to the client, and try to back that up, and I did:that just to see that it worked, and it did. No screen shots here as it’s the same as it was before, so nothing remotely interesting here. Just enough to say that it works like it did and that’s that.
A coworker (hi, DNC) had asked me about backing up a server that was in another domain or a workgroup, but I haven’t run this test because he actually found this:
And that answers the question, for the odd edge cases where it matters, so that’s good. In real life (not lab or enthusiast environments) I would think this would only matter for integrating a new server for media/backup into an existing full environment, but even that is a bit of an edge case IMHO.
So at this point, I’ve covered all of the basic stuff except media and remote access. Unfortunately, I don’t know if I will have time to revisit this piece, but I will certainly try.
Thanks for reading!
Michael C. Bazarewsky
Principal Consultant, Server and Security