Some users were unable to access DFS via the domain name:  The error was

"\\mydomain.com\dfs is not accessible. You might not have permission to use this network resource"

However there was clearly no permissions issue. The users could access the DFS shares just fine via “\\dcname\dfs”.

Once I tried to net view the namespace the problem became clear:

net view \\mydomain.com

DFS   Disk   [Offline Share]
NETLOGON  Disk  Logon server share
SYSVOL  Disk  Logon server share

Windows 7 had become completely convinced that the entire DFS was “Offline” and that appeared to be that.

Instead of trying to figure out why this had happened I decided to disable Offline Files. This was the next problem – I went through the Control Panel and found the message “Offline Files is currently enabled” below a greyed out “Disable offline files” button.

In the GPO, “Allow or Disallow the use of Offline Files” was set to “Disabled”. According to the blurb: “If you disable this setting, Offline Files is disabled and users cannot enable it.”

However this was patently not the case. The setting was Disabled but Offline Files was enabled on the client. (I ran the Resultant Set of Policy tool on the client to confirm it really was inheriting the GPO setting – it was.) As far as I can tell, all this setting does is disable the ability to change the state of Offline Files – without actually disabling Offline Files!

Finally I had to set the GPO option to “Not configured”. After that I could disable Offline Files on the client and, finally, DFS is accessible!

But the last irritation is that I had to unconfigure this setting in the global GPO. There is no way to override an “Enabled” or “Disabled” with a “Not Configured” at a sub-OU level.

We were hoping it might magically work like the userProxy object in ADLDS, but no.

I was changing the default self-signed Exchange 2007 cert to one generated from the local CA server. So far so normal… BUT whatever I did I could not get rid of the old certificate!

It was gone from the IIS 7 interface…

   It was not listed by the Get-ExchangeCertficate cmdlet…

      There was no sign of it in the local computer certifcate store…

But every time I attached to the server with IE I was offered that same ^%^$£$* certificate that should have been gone!

After much searching and head scratching I evenually came across this method for manually viewing and changing certs on the SSL port: http://technet.microsoft.com/en-us/library/cc727844.aspx

Running the command

   netsh http show sslcert

showed that, indeed, the old certificate was still bound to the port.

I then used the following command to get rid of the old one:

   netsh http delete sslcert ipport=0.0.0.0:443

And finally the following command to add the new cert:

   netsh http add sslcert ipport=0.0.0.0:443 certhash=hash appid={00112233-4455-6677-8899-AABBCCDDEEFF}

The hash you can copy from the Thumprint value when you run a Get-ExchangeCertificate in the Exchange Command Shell.

As for the appid – I tried to find out what was supposed to go here, and in the end just used the default GUID. It worked fine.

After doing all of this the old cert was finally well and truly gone, and I could attach to Exchange 2007 using the new cert.

This all seemed rather a lot of effort, and none of the documentation I read said any of this netsh stuff would be needed – perhaps a bug with Exchange 2007 on Windows 2008?