One of my customers had problems with certain users being member of a lot of Active Directory groups. This resulted in several client side issues. There’s an easy and well-known “fix” for that: raise the MaxTokenSize registry key on all Windows operating systems in your domain. On Windows 8(.1) / 2012 (R2) the MaxTokenSize is already at its maximum (advised) value out of the box. That value is 48.000 bytes. In order to mitigate these users their access problems we raised the MaxTokenSize to 48.000 bytes on all clients and servers that are running Windows 7/ Windows 2008 R2. After this change the typical issues were gone. However new ones came up:

From time to time, when HTTP is involved, issues were encountered:

• Opening the Direct Access management console (depends on WinRM)
• Open the FIM Portal
• Streaming App-V packages over HTTP
• …

Typically the user would receive several authentication prompts and even after specifying valid credentials another prompt would reappear. Example browser based issue:

As you can see the browser gives an HTTP 400 Bad Request error. Using a network trace we can easily see why it’s considered bad:

And the packet details:

The details clearly state that The size of the request headers is too long.

The problem here is that the token is allowed to be up to 48.000 bytes where it used to be 12.000 bytes. The http subsystem of a windows server has several parameters that are supposed to protect the server from oversized requests. However, as the token can now be a lot larger, the maximum request size has to be tuned as well:

From: KB820129

Below: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters there are two interesting values:

And from: KB2020943 we can find a formula to calculate the MaxFieldLength to set based on the MaxTokenSIze.

If MaxToken is 48.000 bytes (default in Windows 2012 and configure by GPO for 2008 R2/ Win7):

• (4/3 * 48000) + 200 = 64200

We’ll use the maximum allowed value of MaxFieldLength 65534 (=~ 64200) to allow tokens up to 48000 bytes. We’ll also use this value for MaxRequestBytes.

• MaxFieldLength: we can take the maximum allowed value: 65534
• MaxRequestBytes:  65534

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

Other useful information:

• http://blogs.msdn.com/b/ashishsingh/archive/2010/04/03/windows-authentication-for-accounts-with-large-kerberos-tickets-may-not-work-despite-having-maxtokensize-in-place.aspx
• http://www.grouppolicy.biz/2013/06/how-to-configure-iis-to-support-large-ad-token-with-group-policy/

I specifically wanted to post this information as in many other only articles/posts I always see people just using the maximum allowed value for MaxRequestBytes and I don’t feel 100% comfortable with that. Second,  in my opinion it’s advised to have these values pushed out to all your server systems. Especially now that Windows 2012 and up have a MaxTokenSize of 48.000 by default. If you don’t push these HTTP.sys parameters, you’ll end up troubleshooting the same phenomena multiple times from different angles. Why waste time?

One of my customers is deploying Windows 8.1 clients. They mainly use SCCM and App-V as a software delivery solution. Besides that they also have some applications published over RemoteApp. Windows 8 has a GPO setting which allows you to configure the RemoteApp Connection URL: Setting the default RemoteApp connection URL on your clients using GPO

My customer mentioned to me that some of the clients got the following error message: There are currently no connections available on this computer.

Verifying the RemoteApp and Desktop Connections event log showed no entries. I double checked that the GPO was applying by checking the following registry key:

• Key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Workspaces
• Value: DefaultConnectionURL: https://termsrv.contoso.local/rdweb/Feed/webfeed.aspx

I did some googling and stumbled upon the following articles:

• RemoteApp Default Connection URL Group Policy not working
• Default Connection URL via GPO 2012 server / windows 8 client

The first one didn’t apply for our situation. Our clients were not part of any VDI or TS setup. The second one seemed interesting. Sadly no solution was given, but it gave us the hint that adding the user to the local administrators might help. And indeed this made the RemoteApp Connection URL work. If adding a user to the local administrator is a solution for any given problem, this means you got to tweak one of the below:

• Permissions in the registry
• Permissions on the file subsystem
• User Rights Assignment (GPO/Secpol.msc)

I removed my user from the Local Administrators and started testing again. Using process monitor I couldn’t see any particular access problems for either file or registry. What I did learn from process monitor though is that a part of the RemoteApp configuration is handled by a group of scheduled tasks! I could clearly see these being created as an Administrator, but not for my regular account. Here’s how they should look:

So somehow the creation of the scheduled tasks went sideways. I thought I ‘d be smart and I started with enabling all failure audits for all events in the security event log: auditpol /set /category:* /failure:enable. Whilst I could see some events being generated during my logon, I couldn’t relate any of those to the scheduled tasks not being created. So no clues there. The only thing I figured I could do is start examining the user right assignment settings. This customer has implemented the security recommendations (Security Compliancy Manager) which means a lot of these are customized. After I put my client in an OU with NO GPO’s whatsoever I could see that my user got this RemoteApp configured just fine.

I thought this would be an easy job. I started comparing my user right assignments on the client (with no GPO’s) and the ones being set by GPO. Typically I would need to hunt something down where by default users have the right, but where the GPO is more strict and only Administrators have it. After going through the list I had found none of those…

So I cloned the GPO, made sure the original one no longer applied to my client and started setting settings to not configured in the user rights assignment section. Sadly I started at the bottom because the one which seemed to be the culprit is Act as part of the operating system. The GPO seemed to set grant this right to “Authenticated Users”. That made me frown… It seems like a very privileged thingy to grant to authenticated users… From the SCM 3.0 toolkit you can see that both the default and the advised setting is “None”:

It seems that somehow the GPO got wrongly configured at some point in time. By default this is set to “None”. After removing the authenticated users from this particular setting I was finally able to get my user his RemoteApp configuration up and running:

This is the setting which seemed to be having this negative effect:

I ‘m still trying to wrap my head around the fact that whilst this setting had authenticated users in it, only non-administrator users were impacted. Either way, case closed!

A while ago I posted a workaround to manage the more advanced settings of wireless networks: Win 8 Client (Dev Preview): Manage Wireless Networks, Where Art Thou?

In some of the comments I read that in the final version the explorer.exe shell:: command did no longer worked. After verifying on my own fresh install I noticed that this was indeed the case. However, there’s other possibilities which make it less bad. You can now access the advanced settings in the followings ways:

1. Just before finishing the creation of a new network:

In the network and sharing center click “set up a new…”

Choose “Manually connected to a …”

After entering some basic parameters you can choose “Change connection settings” before clicking close.

2 For an existing network connection:

Ok, my title is a bit misleading, I think you can only edit this one if the SSID is actually accessible. Meaning you are actually in the physical location where the Wireless LAN is supposed to be. So I’m not saying authentication should succeed, but the SSID should be “online”. So in a lot of situations this might be sufficient.

When clicking the network item in the tray a bar will appear to the right with your networks in it. You can right-click it and choose “view connection properties”.

3 By deleting and re-adding the profile:

Yep, this one is not funny, but for now I don’t see any other options. I actually found this one on the following blog: Ryan McIntyre : Windows 8 Missing “Manage Wireless Networks”

• Show the profiles: netsh wlan show profile
• Delete a profile: netsh wlan delete profile “profile name”
• Recreate it using the GUI and make sure you now do it properly

Ok, I’ve gone through my mailbox and I’ve got quite some little neat tricks I want to share and most of all never forget myself. So I’ll put them here for future reference.

Tip #1 (Network):

Remember “Network Tracing Awesomeness” If you’d only want to have traffic captured which involves a specific IP you can start the trace like this:

netsh trace start capture = yes ipv4.address=10.90.101.41

This can be very convenient if your server is a domain controller or a file server and communicates with a lot of clients all the time.

Tip #2 (IIS):

In various IIS Kerberos configuration howto’s you are instructed to set useAppPoolCredentials to true. I Always hate editing XML’s directly as it’s quite easy to make errors. Using the following command you can easily set this parameter from a command prompt:

appcmd set config "Default Web Site" /section:windowsauthentication
/useAppPoolCredentials:true /commit:MACHINE/WEBROOT/APPHOST
(the command is supposed to be on one line)

The Default Web Site is the name of the site as it appears in the IIS management console. Remember, you might need to have something like Default Web Site/vDir If you have to configure this for sublevels of the site.

Tip #3 (Kerberos):

If you enable an account to be trusted for delegation to a given service, you might have to wait some time before the service itself notices this. This is often noticed as: I changed something, it didn’t work and magically the next day it started working. If I’m not mistaken, this might have to do with the Kerberos S4U refresh interval which is at 15’ by default. At least that was the value at Windows 2003… See also: KB824905: Event ID 677 and event ID 673 audit failure messages are repeatedly logged to the Security log of domain controllers that are running Windows 2000 and Windows Server 2003

Tip #4 (PowerShell):

From: MSDN: Win32_PingStatus class

When you use PowerShell to perform remote tasks on a server, such as WMI queries, it might be way more efficient to do a quick ping before actually trying to talk WMI to the server. This way you can circumvent those nasty timeouts when the server you are trying to talk to is down.

$server = "server01"
$PingStatus = Gwmi Win32_PingStatus -Filter "Address = '$Server'" |Select-Object StatusCode

Tip #5(Tools):

Every once in a while I need a tool from the Sysinternals Utilities set. Mostly I go to google, type in the name, get to the Microsoft site hosting the utility and click launch. However, it seems you easily access all of the tools using this webdav share: \\live.sysinternals.com just enter it in a file explorer or your start-> run. The utilities we all know so well are located in the Tools folder. Or if that doesn’t works, just use http://live.sysinternals.com/ 

Thanks to a colleague for this last tip!

-Stay tuned for more!-

One of my colleagues was having troubles accessing an HTTPS site. The site is secured with a certificate coming from an Active Directory Certificate Authority. Now I know of a bug where if you have a pinned website on your taskbar, and from that browser instance you open an HTTPS site with an untrusted certificate, there’s no "continue anyway” button…

Now this wasn’t the case today. He had the “continue anyway” option, where you typically click on, load the site and check the certificate. However, after clicking, it didn’t go trough, it just remained at the same page. We installed the root CA manually in the trusted root authorities, but still no improvements. When verifying the root certificate in the MMC we also saw it mentioned that the digital signature was invalid.. odd!

Using that as a query for google we quickly came across this:

• RSA keys under 1024 bits are blocked
• Blocking RSA Keys less than 1024 bits (part 2)
• How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)

If you read those first two carefully you’ll see the update will be released as a critical non-security update on august 14th for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

An example of a bad certificate:

Now how come he was having this issue now already?! Ahah, now comes the clue! He was using Windows 8! Now I am too, and I’m not having that problem with that specific site, but here’s the difference:

• Windows 8 with issue: Windows 8 Release Preview: build 8400
• Windows 8 without issue: Windows 8 Consumer Preview: build 8250

So it seems they’ve included this update somewhere in the build process of Windows 8.

Having certificates with an RSA key < 1024 is probably not really the case for most of us, but be sure to double check those certificates and their (intermediate) roots! Especially for those customer facing sites where you can’t control what updates hit the clients and thus potentially might be denied access to your sites.

A colleague of mine today learned me this neat shortcut: typing windows key + x on the Windows 8 Consumer Preview gets you a small menu with a lot of frequently used mmc’s. See for your self:

I especially like the “Command Prompt (Admin)” and “Network Connections” options. I’ve been using “ncpa.cpl” as a shortcut for network connections every since I started working with Windows 2008. But this might even be faster/easier.

When I started using Windows 8 I wanted to manually define a Wireless Network to connect to. Win 8 really does it best to make this as dummy proof as possible. One of the options I was missing was an overview of all networks I had been connected to in the past. In fact this is what I was looking for:

I might be missing the obvious, or It might be hidden somewhere in the new shiny Metro UI, but I didn’t found it. Here’s how you can start it:

just copy paste “explorer.exe shell:::{1fa9085f-25a2-489b-85d4-86326eedcd87}” in your start – run or a command prompt.

If I ‘m correct, I believe in Windows 7 you can find a shortcut to this in the Network and Sharing Center.

As I’m curious what might have changed in the Windows 8 Developer Preview I decided to promote a server to a Domain Controller. As I’ve done plenty times before I just did “start – run – dcpromo”:

However this time a message pops up that we can no longer do this and have to use the Server Manager experience. Fine by me.

So off we go: the Server Manager has been revamped and extended. Just click add roles.

There seems to be a scenario-based installation,but that’s just for Remote Desktop Services.

Some fancy server selection options.

Just Check AD DS

Required features to be added

Now this is convenient: you get the choice to add some additional features on your way out

Next

Install

Tumdidum

Ready

Back in the server manager we will see a message saying we now need to execute the domain controller configuration part.

Click it, you’ll see an overview of pending tasks.

Scroll to the right and click “Promote this server to a domain controller”
Choose a name for your root domain

I just picked the new Windows Server 8 DFL/FFL

Defaults for my lab or just fine

Now we are presented with an overview of the settings. Read carefully, it says: “The NetBIOS name of the domain: automatically calculated”. Often this might be just fine, but whereas in the past you could specify it in the GUI when following the advanced route, now we will have to go command line.

And very nice: the view script button shows us the outcome of our clickings in the equivalent PowerShell script:

When clicking next some prerequisites are checked. The outcome was red, I didn’t saw that one coming. It seems to be complaining about the DFL I picked…

Back to the DFL selection I lowered it to Windows 2008 R2 and went forward again.

All is fine now.

However I backed out the GUI as I wanted to try to PowerShell script:

#
# Windows PowerShell Script for AD DS Deployment
#

Import-Module ADDSDeployment
Install-ADDSForest `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "Win2008R2" `
-DomainName "addict.local" `
-DomainNetBiosName "ADDICT" `
-ForestMode "Win2008R2" `
-InstallDNS:$true `
-LogPath "C:\Windows\NTDS" `
-RebootOnCompletion:$false `
-SafeModeAdministratorPassword (Read-Host -AsSecureString -Prompt "Enter Password") `
-SYSVOLPath "C:\Windows\SYSVOL"

I could have set "RebootOnCompletion”, but I wanted to see the result of the command.

After rebooting I decided to check the DFL/FFL raising again:

So I guess we will have to wait for that. In the near future I might be adding additional postings regarding Windows 8 Server. However this is all pretty early and stuff might be left out in the final version of course.