Show Control Panel in Start Menu using Registry

If you are using roaming profiles, or even better mandatory profiles, you can set the Control Panel to appear or not appear in the Start menu for all users by editing the following registry key in the NTUser hive:

[HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_ShowControlPanel

1 = Show Link
0 = Hide

We use Appsense to set this key on logon for specific users on specific servers.

Changing the Primary Domain DNS name of this computer to "" failed.

We have been hitting an error when adding Windows 7 and Windows 2008 R2 machines to our Windows 2003 domain, specifically:

.

.

.

.

This issue does not affect older versions of Windows and does not appear to stop the computer from successfully joining the domain. I looked into the c:\windows\debug\netsetup.log and found the Windows 7/2008 R2 perform an additional number of steps at the end of the domain join, things that previous OS versions have not done and the following error is shown:

NetpLdapBin:ldap_bind failed Server:81: Server Down

I am yet to discover exactly what these additional steps do, but it was easy to spot the problem. Throughout the domain join the server contacts the domain controllers using the DC FQDNs. In this last section it attempts to contact the domain controllers using the netbios name, which fails as we do not apply domain suffixes to our servers and workstations using DHCP - we use the standard DNS devolution and setting to apply parent DNS names. If you do use DHCP to apply DNS suffixes you more than likely will not see this issue. If you don't you can work around the issue by adding a manual DNS suffix for your domain before your domain join and then remove it again afterwards (this is how we are working around it for now). Or you could just ignore it as I cannot find any negative side affects.

Microsoft have confirmed this as a bug in Windows 2008 R2 and Windows 7 but have not yet committed to a fix date as they see it as low priority (as it does not break anything). I have requested a KB number from MS, which I will post ASAP.

Your Out of Office settings cannot be displayed because the server is currently unavailable. Try again later.

There are loads of blog entries about this error and numerous causes. It could be that autodiscovery is not working correctly, that the OOF URL is configured incorrectly, permissions are wrong on the CAS servers etc.... I'm not going to go into detail here as there are loads of blogs and articles about this.

Our situation was slightly different to anything I could find. OOF works just fine for our users, however as Exchange administrators we could not set other users OOF when using Outlook 2007, we got the error "...the server is unavailable...". We also found that we were unable to login to other users mailboxes using our Exchange admins accounts using OWA, which was the other way we used to set OOF for absent users. The only way we could still set OOF for end users was to use Outlook 2003, but this is no longer supported on our campus, so we needed another way. This prompted me to get to the bottom of this problem, so we as system admins could again easily set end users OOF.

The one thing that was obvious is that this was a problem that only happened when connecting via the CAS servers. We could login to mailboxes just fine using MAPI. Therefore there had to be something different about the way the CAS servers authenticate users against mailboxes. It is worth mentioning at this point that we had confirmed that our admin accounts were listed as having Full Mailbox Access to all mailboxes in ESM. We soon discovered that the server is unavailable error is a generic error and happens regardless of what error is actually returned by the server. Having tried the URL of the OOF within IE we saw that it was actually an access denied error that was being returned by the CAS server, not a service unavailable error. We were stumpted as our admin accounts had full access!

With some testing I noticed that some of our several thousand mailboxes did allow us to set OOF as admins, but the vast majority did not. The question was why. I then started playing with Full Access permissions and found that any change whatsoever to the Full Access permissions using ESM or the shell suddenly made OOF work for our admin accounts. This is where Microsoft came in as I was stumpted. It turned out that this is apparantly an expected issue that Microsoft have documented very poorly. It is a result of the split permissions model in Exchange 2007. When connecting to a mailbox using a CAS server (as OOF does in Outlook 2007), the CAS server reads the MSExchangesecurityDescriptor from AD. By default this is truncated and incomplete. To cut a long story short, Microsoft no longer support automatically inherited AD permissions to mailboxes, although you will see the permissions using ESM and they will work using MAPI connections. I find this utterly baffling, but it is what it is. In order to resolve this you need to make a change to the mailbox permissions using the shell or ESM. This causes Exchange to rewrite the MSExchangeSecurityDescriptor in AD and suddenly everything works. A couple of methods and further info:

add-mailboxPermission -identity -accessrights:fullaccess

get-mailbox -server Add-MailboxPermission -User -AccessRights FullAccess

http://technet.microsoft.com/en-us/library/aa996343(EXCHG.80).aspx

http://support.microsoft.com/kb/310866