For those interested in the look and feel of the new Web Application Proxy role, here’s some screenshot of a fairly simple next next finish setup.

The installation:

Remark: seems I’ll have to add a server to my lab environment

The Configuration:

The Management Console:

Open the Remote Access Management Console

The Publish New Application Wizzard:

Remark: read the explanation of the ADFS selection bullet, it’s fairly descriptive.

Seems like basic internal <> external stuff.

Remarks:

• Active Directory Federation Services and Web Application Proxy can’t be combined on one server.
• Active Directory Federation Services is to be installed in your domain before you can install the Web Application Proxy as you need to specify it.
• Selecting Pass-Through on the Preauthentication screen will skip the Relying Party selection and then your application will handle the authentication. This will break your users their SSO experience though.

Just for those interested, here’s the screenshots of the ADFS installation on a Windows 2012 R2 Preview installation. Before 2012 R2 it wasn’t advised to install ADFS on a domain controller as the ADFS solution relied on IIS. But with the 2012 R2 version the IIS dependency is gone and Microsoft recommends installing ADFS on domain controllers. I think this will lower the bar for a lot of companies. Also the enhanced authentication options (multi factor) seem really promising.

The installation:

Remark: in the end my system didn’t need to reboot

The configuration:

Remark: small sidestep here: obviously I want to use Group Managed Service Accounts!

Remark: lab only procedure: ensures Group Managed Service Accounts are available immediately

The management console with the focus on the new Authentication Policies section

A new Relying Party Trust type:

If I read the explanation correct this will allow you to publish non claims-aware application over the new Web Application Proxy role.

Remarks:

• The option for a stand alone ADFS server is no more. Either you install a single node farm or you install a real farm. Makes sense to me.
• You still have the option to choose between a Windows Internal Database or a dedicated SQL Server database. This might be a hard choice. I’m not sure I’m happy to have Internal Databases running on my domain controllers. The SQL on the other hand requires a cluster for proper availability which might be quite expensive to sell to your customers.
• Named certificate forces you to take the subject of the certificate as the Federation Service Name. Wildcard certificate allows you to pick freely as long as the wildcard is respected. It seems you can have additional . in the wildcard part though. I advise against this as you’ll probably face certificate validation errors in your browser. Example: *.realdolmen.com allows you to select sts.sub.realdolmen.com.
• More on Group Managed Service Accounts: vankeyenberg.be: Why you need group managed service account and how to use them and Ask PFE Platforms: Windows Server 2012: Group Managed Service Accounts
• If you want to compare=: the Windows 2012 ADFS installation: vankeyenberg.be: ADFS Part 1: Install and configure ADFS on Windows 2012
• The Authentication Policies section in the management console seems awesome. Very clear and it seems very easy to manage.

A while ago I wrote this post: Windows 7 & Reverse Lookup DNS Registration One of the problems with the approach was that adding the command: netsh interface ipv4 set dnsservers name="Local Area Connection" source=dhcp register=both only worked for the wired network adapter. We’re having more and more PC’s connecting over a recently installed wireless network and also our machines connected over VPN aren’t properly registering their reverse records. The reason for this is that both Wireless and VPN connections come with their own adapter with it’s own setting.

We played with the idea of scripting our way round this to get all adapters this particular setting, but I figured I’d give another attempt at looking for the right GPO which should do this with way less hassle. And here it is:

The GPO which does the exact same thing as the netsh command, or checking the checkbox Use this connection’s DNS suffix in DNS registration is located below Computer Configuration > Administrative Templates > Network > DNS Client. It’s called Register DNS records with connection-specific DNS suffix. I have no idea why I didn’t managed to find this one 2 years ago, but better late than never. This GPO will set the registry value RegisterAdapterName to 1 below the Policies hive. In fact, the netsh command or the checkbox I mentioned before will set the exact same key but then below the guid for that specific adapter.

Note: whether or not it’s a best practice to let clients register their own reverse records in stead of the DHCP server I’ll leave in the middle. In my situation the DHCP is a non-windows based solution and our DNS zones only allow secure updates. Therefor we choose to have the clients to the updates themselves.

When trying to avoid the usage of temporary profiles (see: Setspn: Temporary Profiles and IIS Application Pool Identities) I had to resolve some SIDs (Security Identifiers) to AccountNames. Using PowerShell this can easily be achieved:

• $objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-21-xxxxxxxxx-yyyyyyyyyy-zzzzzzzzz-10472");
• $objUser = $objSID.Translate( [System.Security.Principal.NTAccount]);
• $objUser.Value

Happy resolving!

Lately we had to stop (and start) the SharePoint Foundation Web Application services and the Central Admin services on several servers. We noticed that the bindings that were previously active were now totally different from what they were.

Some background: we got some SharePoint Web Applications which are made available over Claims Authentication. In order for these applications to be crawled by the Search service we extended them so that they could be made available over Windows Authentication. Besides that, we also had some URL and TCP/IP Port changes over the past year.

It seems that we did several changes on Alternate Access Mappings (AAMs) (SharePoint Central Admin) and on the IIS bindings (IIS Management Console). And that’s where the problem lies. When you create a Web Application, or extend it, you are asked some parameters (like host headers), and these are stamped in the SharePoint configuration database. These are the settings that are used when you start the “SharePoint Foundation Web Application service” on a given SharePoint server. When you modify AAM’s or IIS bindings, these settings become inconsistent.

Here’s how you can retrieve what’s currently known for your web application:

• $web = Get-SPWebApplication -Identity https://site.customer.com
• $iisDef = $web.GetIisSettingsWithFallback("default")
• $iisDef.ServerBindings
• $iisDef.SecureBindings

If you are interested in the settings (bindings) of an extended site, you have to pass the correct zone along. E.g. for the custom zone:

• $iisCust = $web.GetIisSettingsWithFallback("custom")

Now I tried editing these in several ways, but it seems like this information is really read only. The only way I found to modify these is to go through the Central Admin web application management section and choose the “remove SharePoint from this site” option when selecting a web application (below the delete button). Afterwards you can extend the web application again. I performed this for several sites and it’s not really that painful. Don't forget, your site becomes unavailable in the whole farm as it's deprovisioned and re-deployed afterwards. Obviously this can be scripted as well.

Here’s the source of my information: MSDN Blogs: How to properly change the Host Header URL of a web application in SharePoint 2010

Things I’ve learned #1: the things I conclude from my tampering with web applications:

1. There’s no way to specify what IP to listen on when creating a web application/ extending it
2. There’s no way to select a specific certificate when creating a web application/ extending it (you can select “use SSL” though)

Out of these 2 I assume that you can modify these directly in IIS without breaking anything. Obviously if you start the SharePoint Foundation Web Application service it’s up to you to (re)do the proper IIS configuration.

Things I’ve learned #2:

1. Always specify a host header. for port 80, for use SSL and for custom ports.

As SharePoint doesn’t allow you to specify an IP, you’ll be blocked from creating an other site with “use SSL” checked if you don’t specify host headers.

Things I’ve learned #3:

Perhaps a bit dirty, but we noticed that some of our sites weren’t being added in IIS. The following lines re-triggered the registration of the web application in IIS without having to stop and start the SharePoint Foundation Web Application service.

• $web = Get-SPWebApplication https://site.customer.com
• $web.ProvisionGlobally()

Lately we got notified of a small bug in our claim provider we deployed on a SharePoint 2010 farm. In short, when using the “regular” people picker results were being returned just fine. It allowed people to search for both user and group claims. Now it seems that you can modify the behavior of the default picker. The default one results in a picker which is called "Search for People and Groups”. But by specifying some parameter of the field you are defining you can also force it to only “Search for People”. The latter however didn’t returned anything.

Here’s a small overview of the allowed types: MSDN: SPFieldUserSelectionMode

• UserSelectionMode = PeopleAndGroup

• UserSelectionMode = PeopleOnly

We still didn’t had any clue why the people picker wasn’t returning anything. So we decided to double check our code behind the searching and resolving. The only reason we found that could cause the people picker to return nothing was this line of code:

if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
      return;

To be honest we had that line in there because we created our custom claim provider based upon this sample: MSDN: Claims Walkthrough: Writing Claims Providers for SharePoint 2010 This article has the following statement:

One thing that is important to note here—if you are not creating identity claims, then a claim can be used to provision almost any security item in a SharePoint site except for a site collection administrator. Fortunately, we do get a clue when a search is being performed for a site collection administrator. When that happens, the entityTypes array will have only one item, and it will be Users. In all other circumstances you will normally see at least six items in the entityTypes array. If you are the default claims provider for a SPTrustedIdentityTokenIssuer, then you do issue identity claims, and therefore you can assign one of your identity claims to the site collection administrator. In this case, because this provider is not an identity provider, we will add a special check when we fill the hierarchy because we do not want to add a hierarchy we know we will never use.

After reading that a few times we started putting things together. We added some verbose logging to print the entityTypes and we found out that the only EntityType present was the Users one when searching in the “Search for People” picker. This small if statement exist to prevent you from adding a non-identity claim as a site collection administrator. In our case we can easily adjust or even skip this test altogether because we are using identity claims anyhow! We are not allowing to pick a claim like “favorite color”, which more than one user could have, but we set claims based upon the “UPN” which is an identifier claim in our setup.

Kudos to @ArneDeruwe who originally wrote this claim provider for this project. Together we were able to tackle this problem.

Lately I had to reinstall a UAG server which is part of a two node array. The OS disk got corrupted somehow so a reinstall was necessary. When I wanted to rejoin the newly installed server to the UAG array I got the following error: “This server cannot join the array.” The procedure to add a UAG server to an array is explained in detail here: TechNet: Joining a server to an array

Whilst the procedure is very basic, it’s really important you don’t miss these items:

• Do not join a server to an array during Forefront UAG installation using the Getting Started Wizard.
• Ensure that the Forefront UAG Management console is closed on the array manager server

Also you might have to start some TMG services which are stopped during the initial (failed) attempt to join the array. This article is rather short and if you follow the documentation carefully you shouldn’t run into it. But somehow I did and I couldn’t find much for this error message. So here it is for future reference.