Windows Update – Don’t be restartin’

I’ve started to use my Hyper-V machine to host my development server which I remote in to.  It works great assuming I can actually remote to it (and not blocked by firewall policies).

What is really nice is I can leave it on all the time, so my windows are where I left them.  That is, until Windows Update graciously restarts it for me.

I don’t mind it automatically updating, but do you really have to restart?

This can be disabled through group policy though.

Edit your group policy and navigate to:

Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update

Modify “No auto-restart with logged on users for scheduled automatic update installations”

Home Networking: Configuring Forefront TMG for Web (and SharePoint) publishing

Note: I am using this on my home network.  I have not configured this in a production environment.  These are the steps I took to get this working for my network.

After building your bog-standard Hyper-V server with 20Gb RAM, 1Tb HD mirrored, on a quad-core AMD chip (x2), you kinda want to use it as much as you can.  I have used this machine to setup a few personal web site projects, as well as various SharePoint farms.  But more recently I have been using it for SharePoint 2010 testing and exploration. 

I had setup external access to my sites using port forwarding from my D-Link router, but I was having to use a different port for each server.  On top of that, I have a Windows Home Server in the mix, which loves to grab port 80 from my router through UPnP.

Game Plan

Here’s what I’m trying to do.  Have three internal web sites, http://www.mydomain.com, sp2010.mydomain.com, sp2007.mydomain.com.  Make all of these accessible from the internet using Forefront TMG.  Setup Dynamic DNS to manage my dynamic IP.

Players

Forefront TMG – The next generation of Microsoft ISA server.  Forefront TMG will handle traffic for the 3 three web sites.

DynDNS.com – Will handle the dynamic DNS for me.  There are several alternatives, I just happened to pick this one.

D-Link router – The router will handle directing all traffic to the TMG server on port 80.

SharePoint AAM – We need to configure SharePoint to understand the addresses it will receive.

Windows Home Server – Not a direct player, but it does hijack port 80 from the router, so need to disable this.

Assumptions

• All web servers have a static IP address.
• Forefront TMG is already installed and configured.
• Web Sites are available on port 80
• you have a valid domain name (e.g. mydomain.com) and can manage the DNS for it

Testing

While I was setting this up, I used the local hosts file (c:\windows\system32\drivers\etc) to test 1st that the web site host header (and SharePoint AAM) was working correctly by pointing the web address directly at the server; then by testing the TMG firewall rule by pointing the web address at the TMG server.

Publishing a SharePoint Web Application

The following will setup a rule for a SharePoint web application, the same steps will apply for a standard web application, without the SharePoint configuration piece obviously.

We have our SharePoint site already built and hosting a site collection, so now we need to do the following to get it published at sp2010.mydomain.com:

• Configure Alternate Access Mapping (see end of this article)
• Create local hosts entry for SharePoint web server (for testing only)
• Create Firewall rule in TMG
• Edit local hosts entry to point to TMG server (for testing only)
• Configure DNS entry
• Edit router rules (one time)
• Disable Windows Home Server Port Configuring service (optional)

Forefront TMG

 

My configuration for a TMG server is a stand-alone server in a workgroup as opposed to a domain.  Because it’s already inside my network, I have it configured it for a Single Network Adapter.

 

From the TMG Console, open the Firewall Policy page from the tree on the left.

Before we create a rule for the web site publishing, we need to configure a Web Site Listener (if not already configured). 

Creating a Web Listener

From the Toolbox tab in the right pane, right-click on the Web Listeners folder and select ‘New’.

Using the Wizard to enter/select the following:

• Name: HTTP Web Site Listener
• Connection Security: Do not require SSL
• IP Addresses: Internal (Because this is a single NIC network, all requests will come from internal.)
• Authentication: HTTP Authentication for Basic, Digest, Integrated
• SSO: No SSO will be available as we are not using Just forms authentication.

Once the wizard is complete, you will see the listener listed in the folder.

Double click to bring up it’s properties and make the following modification.

Under the Authentication tab, click Advanced…

Select to “Allow client authentication over HTTP”.

This is disabled by default as you would typically authenticate over SSL for an external connection.

 

 

 

 

 

 

Now that the Web Listener is created, we will use this when creating our rules.  So on to our Firewall Rule.

Creating a Firewall Rule

Switching back to the Tasks tab in the right pane, select Publish Web Sites. 

Note: There is also a Publish SharePoint Sites option. From what I could see the only difference is that the wizard asks if you have configured Alternate Access Mapping for the site – it does not seem to do it for you; making it no different to the Publish Web Sites wizard.

Use the wizard to provide/select the following:

• Rule Name: sp2010.mydomain.com
• Rule Action: Allow
• Publishing Type: Publish a single Web site or load balancer
• Server Connection Security: Use non-secured connections
• Internal Site Name: sp2010.mydomain.com
• Internal Publishing Details: Select to forward original host header
• Public Name Details: Accept requests for this domain name (sp2010.mydomain.com)
• Web Listener: Select the one created earlier
• Authentication Delegation: No delegation, but client may authenticate directly
• User Sets: All authenticated users

Once you are happy with the rules and Web Listener, you need to apply them.  You will see an Apply button at the top of the window.

After the rules are applied, we can test by pointing the local hosts entry at the TMG server IP address.

 

Router Configuration

In order for us to access this internal web site from the outside, we have to configure the router to handle the traffic accordingly.  My router is the excellent D-Link DIR-655.

The configuration involves setting up virtual servers for the web sites.  Because we are having Forefront TMG handle all the redirection, we only need one virtual server entry that sends all HTTP traffic to the TMG server.

From the D-Link management console (web application), Select Virtual Server under the Advanced tab.

 

Enter information for a new virtual server that will send all HTTP traffic (port 80) to the IP address of the TMG server.

Now when you apply this rule, all HTTP traffic will be immediately passed to the TMG server to manage.

 

At this point we can test to see if:

• Router is forwarding HTTP requests
• TMG firewall rule is handling correctly
• Web site AAM is configured correctly

To test, modify the local host entry to point to the public IP address of your router.  To get this address, browse to www.whatsmyip.org from inside the router.

 

Dynamic DNS

Because this is a home network, running off a cable provider network, I do not have a legal dedicated IP address.  Instead my cable provider allocates me a dynamic one.  Because of this, I cannot directly bind my web address sp2010.mydomain.com to a static address :(.  This is where DynamicDNS fits in :).  A dynamic DNS address gets updated when the ip changes, this update is handled by a client on the network talking to the DynamicDNS server.

To get DynamicDNS working, you need to register with a DynamicDNS provider (dyndns.com in this case), and a client to update the server.  There are plenty of free clients out there, but most modern routers can act as a client also.

So I registered mydomain.dnsalias.com at dyndns.com, then I configured my router to updated it.

Now when my cable provider assigns me a new IP address, the router will update mydomain.dnsalias.com accordingly.

 

Sweet.

 

 

At this point, you could test by pointing the entry in the local hosts file at mydomain.dnsalias.com.  In order to test this though, you have to configure your firewall rule, IIS host header, and SharePoint AAM accordingly.

 

Domain Configuration

All we have to do at our domain provider, is create a CNAME for sp2010.mydomain.com that points to mydomain.dnsalias.com.  Once that propagates, we should be able to ping sp2010.mydomain.com and have it resolve to our public IP address!

 

 

Windows Home Server

The last piece of the puzzle for me was to stop my Windows Home Server from overriding my router Virtual Server settings for port 80.  WHS provides for publishing it’s own web site for accessing pictures, files etc.  It’s actually great, and completely handles you having your own address at mydomain.homeserver.com, including providing an SSL certificate, and automatically configuring your UPnP router.  This is all great until you don’t want it to :). 

There are a number of ways to tackle this.  you could disable the UPnP feature of your router altogether, but doing this will mean other applications could not use it.  You could disable the service by remoting into your WHS (but WHS can still re-enable it).

I just opened up the WHS console and disabled it from there.  Because I never use it, this is the easiest option for me.

To disable this through the console, Open the settings window and click Remote Access on the left.

Here you can click the Turn Off button to disable the service.

 

 

 

 

SharePoint Alternate Access Mappings

Lastly, if you haven’t configured SharePoint already (and you probably have to have had successful tests), here’s what you need to do for SharePoint AAM and IIS.

From SharePoint Central Administration, select Configure alternate access mappings in the System Settings group.

 

On the AAM page, edit the Public URLs (make sure you have selected the right web application).

Enter http://sp2010.mydomain.com for the internet url.

 

 

Any changes to the AAM after the web site has been extended for SharePoint, will have to be manually applied to IIS.

Open IIS Manager, and browse to the web application. Right-click and select Edit bindings.  add a new binding for sp2010.mydomain.com.

 

Note: I’m using Windows server 2008 R2.  So IIS 7 considers host headers as ‘bindings’.  In IIS 6, bring up the web site properties dialog and modify the host headers in there.

 

Conclusion

Forefront TMG gives you much more control and functionality that what I am currently using it for, however this is all I need right now.  As mentioned before, this is not a production environment.  For a production setup, more attention should be paid to authentication and encryption using SSL.

The same steps apply for creating a standard web application without the need to configure SharePoint.  You will still need to configure IIS bindings however.

Now you should be able to access your externally published SharePoint and Web sites from wherever you are!  No excuses ;).

Configuring Forms Based Authentication for SharePoint 2007 using IIS 7.

Enabling Forms based authentication is much easier with IIS 7.  With IIS 6, you were required to create your membership store (database), then modify the config.xml file to add connection strings, membership, and role details.  Once you had everything configured, you then needed to populate the store; the typical approach was to use the web site administration web application through Visual Studio.  Not ideal if you’re on a production farm!

With IIS7, you still need to create the membership store, but you no longer need to edit the xml config file manually, or whip up an ASP.NET app just for the purpose of managing the users.  Everything is handled through the IIS Management console.

The new IIS Management page offers many options.  You will notice four that we will use for configuring FBA:

• Connection Strings
• Providers
• .NET Roles
• .NET Users

The Membership Store

The membership store is still created using the ASP.NET SQL Server Setup Wizard.  This is launched from the .NET 2.0 Framework folder on the server at:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe

This wizard will take you thorough the steps and will build out the SQL database for you.

Once you select to Configure SQL Server for application services, you will be prompted for the SQL Server name and database name.  You can choose an existing database to add the membership elements to, or you can type in a new name and the database will be created for you.

Once the database is created, we need to configure IIS to use it.  Switch to IIS Manager, and select the web site that we want to enable FBA on (in this case it’s SharePoint – Extranet), we then need to configure the connection string, the provider, roles, and users.

The Connection String

From the ASP.NET section in IIS Manger, open the Connection Strings page.  Add a new string for the membership database.

NOTE: We are using a sql account, so mixed-mode is in use.

Make sure to spell the database name correctly, as you do not get to pick it from a list.

The Provider

We need to add a role provider and a membership provider.  To do this, open the Providers window and click Add while in each feature:

.NET Roles

.NET Users

The .NET Roles

Once we have defined the providers for our Roles and Members, we can define the roles we want to use.

Open the .NET Roles page.  Set the default provider to FormsAuthRoles.

Click add to add roles for:

• StandardUser
• SuperUser

The .NET Users

Switching to the .NET Users page, we set the default provider:

Then we can add users.

At this point we have configure everything we need for FBA using ASP.NET.  We now need to enable the authentication methods for the web site in IIS, by enabling FBA, and disabling Windows Authentication.  For the SharePoint – Extranet web site, open the Authentication page under IIS.

On this page, disable Windows Authentication and enable FBA.

Now we are set for SharePoint – Extranet.

Before we leave the IIS Management console, we need to setup the connection string, roles and membership providers for the Central admin site.  We do this so we can reference the membership database when managing users through Central Admin.

So for the SharePoint Central Administration site repeat the steps above for:

• Create connection string
• Add .NET roles provider
• Add .NET users provider Use all the same settings as you did previously.

Once this is done, we can launch Central Admin web site to make the switch out SharePoint – Extranet site to Forms Authentication.

Central Administration

Under the Central Admin Applications Page, click Authentication Providers under Application Security.

Making sure you are on the correct web application, click ‘Default’ to edit the provider details.

Here we can set the authentication type to Forms, and then provide the details for the Membership and Role providers.

We also disable Client integration.

Were we to test the application now, it would not authenticate us, as we have not added any members.  So we first need to define our site collection administrator.

Back under Central Admin > Applications > SharePoint Site Management section, click Site collection administrators.

Now when you add a user, you will be selecting from the FormsAuthMembers provider!

A quick test of the site will now display the default FBA form login.aspx

Next we need to throw some style on that login page!

Server 2008 – Hosts file locked…. not really.

When is an Administrator not an administrator?  When you’re trying to edit the hosts file in Notepad++ but you didn’t run it “as administrator” (even though you are one).

I really don’t know why you have to select “Run as administrator” when you are a member of the local administrators group.

Anyways, thanks Guy Ellis for the tip!

Hosts file locked (read-only) on Server 2008