Bennett Adelson Technical Blog

Posts from the consultants at Bennett Adelson

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:

image

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:

image

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:

image

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:

image

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:

image

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:

image

The Getting Started wizard came up at that point:

image

In this case the client was fully patched with all optionally offered components from Windows Update, so the client had everything the Connector wanted:

image

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:

image

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:

image

That gave an interesting prompt in the Connect site:

image

“How do I…” is a link, although that’s not at all clear from the page. Someone went a little overboard on the CSS. Because of IE ESC, and because the Download link uses JavaScript to invoke the download action, it didn’t work. This struck me as silly, even stupid. There’s no excuse for using ASP.NET to make this simple web site doing a simple act. But because it is, I was faced with the choice of turning off IE ESC or adding the site as a Trusted site. I did the latter, although in real life I think I’ve disabled the IE ESC on almost every, if not every, server I’ve ever had to do anything on. I know that would work, but the page tells me to do it a certain way, so I did. When I refreshed, the warning went away, and the download and run worked:

image

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:

image

I put in my account credentials for an administrator and was told, basically, “don’t do that!”:

image

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:

image

So I decided I’d let the client go for now, and switch back to the server, where I saw something very interesting:

image

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:

image

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:

image

So I checked the date/time information and it was fine. But the server showed something more interesting:

image

Active Directory Certificate Services denied request 7 because The revocation function was unable to check revocation because the revocation server was offline. 0×80092013 (-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!

image

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:

image

After the reboot, there was an automatic login, then a prompt for the computer’s description:

image

This is not that different than the previous product releases. This is also true of the backup wake prompt:

image

I was then asked about the CEIP:

image

The user profile was migrated:

image

There was a quick “configuring the computer” step I didn’t get a picture of, then a download of the full Connector software:

image

The computer was then “connected” to the server:

image

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:

image

And told me it was done:

image

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:

image

The login worked, and my Desktop came back correctly, with the new look of the Launchpad showing up:

image

The three complaints were about lacking virus and spyware protection and not having Windows Update configured, all of which is accurate:

image

But one interesting thing in the viewer that I didn’t expect was this:

image

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:

image

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:

image

So I restarted, and again I got the screen for profile configuration:

image

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:

image

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:

image

The executable was there, it just didn’t launch:

image

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:

http://tinkertry.com/windows-server-2012-essentials-fine-with-pcs-in-domain-or-workgroup/

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

2 Comments

    Trackbacks

    1. Windows Server 2012 Beta Essentials Install Walkthrough | Bennett Adelson Technical Blog
    2. Windows Server 2012 Beta Essentials #2 | Bennett Adelson Technical Blog

    Leave a Reply or Comment

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    Follow

    Get every new post delivered to your Inbox.

    %d bloggers like this: