Update: Fixed it for a while, then it broke again. Come to the conclusion that the Windows 7 Task Scheduler is just irreparably broken as I’ve had this happen time and time again. Some 3rd party application is interacting with it in a way that reliably breaks it and I’ve never been able to narrow it down.

Yes, this one again.

When you open up the Task Scheduler, you get a message that says:
“The selected task “{0}” no longer exists. To see the current tasks, click Refresh.”

And you can’t view half your tasks any more, though if you run a SCHTASKS /Query /FO LIST you’ll see that they’re all still there and seem to be working.

I’ve toyed around with a lot of different solutions for this, but I’ve finally found one that fixed it for me:

Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Tracing\SCM\Regular and set or add REG_DWORD TracingDisabled to 0 and then reboot.

My only concern is that this may be generating a trace log somewhere, but I’ve been unable to find anything that suggests this is the case so far.



If you have a 2008/R2 failover cluster then it’s possible you may come across the following errors at some point after an unplanned failover:

Unable to obtain the primary cluster name identity token

An attempt has been made to operate on an impersonation token by a thread that is not currently impersonating a client

As a result, your clustered resources may refuse to start.

Now, assuming that you haven’t done something stupid, like deleting the cluster computer account from AD, you should be able to resolve this problem by right-clicking on the failed CNO on the Summary page of the Failover Cluster Manager, go to “More Options” and then “Repair Active Directory Object”. You should then be able to start all the cluster resources successfully. Thanks to wonhchoi.com for pointing me in the right direction.

As to what might have caused this problem in the first place? Well that’s still something of a mystery to me at the moment…



Situation
You’re using PrintBRM.exe to migrate printers between servers (or to backup and later restore them on the same server) but when it tries to restore the print queues it fails with “Failed to restore print queue <Printer name>. Error 0x800706d9”

Cause
PrintBRM tries to query the Windows Firewall when it creates the shares for the print queues. If the Windows Firewall service is disabled, this step fails and the print queue is not created.

Solution
Start the Windows Firewall service (and make sure you either have physical access to the box, iLO/DRAC access, have already configured the firewall not to protect your network interfaces by default or have put an exception in for inbound RDP traffic, otherwise starting the service will lock you out of the box) and run the PrintBRM restore again.



I ran into an issue this morning with a pair of Windows 2003 Server DCs that were set to sync their clocks using NT5DS (which is the default and means they should sync from the domain hierarchy, which for DCs is often the PDC emulator). They kept logging the following error in the System Log:

The time provider NtpClient was unable to find a domain controller to use as a time source. NtpClient will try again in 15 minutes.

After much prodding, swearing and Googling, it became apparent that with 2003 if a DC has ever held the PDC Emulator role then it will still think it is the authoritative time source for the domain when that role is moved off it. This meant that we had 3 DCs all thinking that they were the One True Time Source and all being out of sync with each other by 2 or 3 minutes.

This issue can be resolved by running the following command on the former PDC Emulator(s): w32tm /config /syncfromflags:domhier /reliable:no /update which will tell the DC that it is no longer a reliable time source and so it should check for updates from a source that is (i.e. the PDC). You can speed things up a bit by issuing a w32tm /resync command to force the Windows Time service to update.

You can use w32tm /stripchart /computer:<PDC Name> to see in real-time how the local clock differs from the time on the PDC Emulator (The o: value) as the time service attempts to bring it back into sync.



The following will get all account lockout events from all writable domain controllers in the current domain and output the information to a text file. Active Directory Powershell Module is required.

ipmo activedirectory;$(Get-ADDomainController -Filter  {(OperatingSystem -ne "") -and (IsReadOnly -ne "True")} | %{Get-WinEvent -ComputerName $_.name -LogName security -FilterXPath "*[System[EventID='4740']]" | Select machinename,TimeCreated,@{Label='User Name';Expression={$_.Properties[0].Value}},@{Label='Client Name';Expression={$_.Properties[1].Value}}}) | Out-File C:\temp\lockout.txt


Update: There is a hotfix now available to address this issue, though you have to ring MS support directly to get hold of it at the moment. The plan is to roll it into an IE9 update in the near future. More details can be found here

There is a known issue with the Exchange 2007 and Exchange 2010 Management Consoles on machines with Internet Explorer 9 installed. This issue causes you to recieve the error: “You must close all dialog boxes before you can close Exchange Management Console.” when trying to close the EMC even though there aren’t any dialog boxes open.

As it stands, there are several workarounds: You can uninstall IE9, you can kill the MMC process from task manager every time and a few people have reported success with turning off “Internet Explorer Enhanced Security Configuration” for Administrators and Users (Servers only) and then adding https://localhost to the “trusted sites” in IE.

According to the Senior Program Manager for Internet Explorer Product Quality, Mark Feetham:

[…]we do now understand what’s occuring between the EMC, MMC and MSHTML. We have enough information to complete the investigation and have moved to looking at ways to improve this situation.

Rumoured ETA for a fix is Q4 2011.



I have previously completed some work for a mid-sized organization and some of the things I’ve come across in the few shorts weeks I’ve had access to their systems are, frankly, astonishing. I’ve barely even scratched the surface and we’re already well into “so bad it’s not even wrong” territory here; a few examples:

  • Critical Servers not under warranty
  • Critical Servers not backed up
  • Servers backed up to disks on the same disk array as the live data
  • Backups taken to tape and then left in the tape loader indefinitely
  • Servers not patched, ever
  • Antivirus not installed on servers, or installed but disabled “for performance reasons”
  • Server hardware/software not monitored
  • Speed/Duplex on all network interfaces set manually
  • Public address ranges for internal network addressing
  • A single broadcast domain for all devices on the network
  • 120m+ Ethernet cable runs
  • Cat3 cable runs within the core infrastructure (undocumented)
  • New user credentials sent by email, via an externally hosted mail system, to user’s line manager
  • All IT Staff granted unaudited access to the entirety of the file servers
  • All IT Staff local admins on all servers

And that’s just the stuff I’ve found so far and haven’t already repressed. I honestly have no idea where to begin, if there were such a thing as a Worst Practice Guide they’d have not only followed it to the letter, but added their own extensive appendices as well.



As per this Technet Blog entry, Outlook doesn’t know what it’s talking about when it comes to retention policies if you’re running in Cached Exchange Mode. This means that even though the Exchange server is correctly applying your policy, Outlook may well report that your items have expired when they haven’t.

…The conclusion here is that if you’ve applied Retention Policies to any of your folders and the items are being shown by Outlook as expired, but are still there days later, take a quick look at them in OWA or an online mode Outlook profile and see if they really are expired.

Straightforward, understandable, but still annoying 🙂



Once more I find myself in the trenches, battling bravely with Exchange 2010 in a vain attempt to beat it into submission. As there’s nothing worse than coming across problems that, when Googled, return only a handful of results, all asking the same thing and without any clear or satisfactory answer, I am providing the following bits in the hope that it might help others in the same situation.

First up, thanks to: flamingkeys.com; if you’ve got Receive Connectors with lots of Remote IP Ranges (Usually to allow them to relay mail externally through Exchange) then the following will make it nice and easy to copy said ranges when you create a new connector. The AuthMechnaism & PermissionGroups take any combination of the below listed options, comma-separated, of course:

New-ReceiveConnector [Connector Name] -Server [Servername] -Bindings [Server IP]:25 -RemoteIPRanges (Get-ReceiveConnector "[Existing Servername]\[Existing Connector Name]").RemoteIPRanges -AuthMechanism [None,TLS,Integrated,BasicAuth,BasicAuthRequireTLS,ExchangeServer,ExternalAuthoritative] -PermissionGroups [None,AnonymousUsers,ExchangeUsers,ExchangeServers,ExchangeLegacyServers,Partners,Custom] -MaxMessageSize [Size with B/KB/MB/GB]

Next, certificates. For no good reason, Microsoft changed the behaviour of the New-ExchangeCertificate and Import-ExchangeCertificate cmdlets from their 2007 versions in order to make them much harder to use; so, to request a new cert:

New-ExchangeCertificate -GenerateRequest -KeySize 1024 -SubjectName  "c=[Country Code],s=[State],l=[City],o=[Org],ou=[Department],cn=[Common name]" -DomainName [Comma separated list of hostnames for SAN] | Set-Content -Path "[Path for CSR Txt file]"

Then, to import and enable the new certificate:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path [Path to Certificate] -Encoding byte -ReadCount 0))
Enable-ExchangeCertificate -Thumbprint [Thumbprint of certificate] –Services [IIS,SMTP,IMAP]

To make use of the handy GAL photographs, first have a read of this from the Exchange Team Blog then, use this cmdlet to upload a photo:

Import-RecipientDataProperty -Identity [Mailbox Name] -Picture -FileData ([Byte[]]$(Get-Content -Path [Path To Image] -Encoding Byte -ReadCount 0))

And this one to remove it:

Set-Mailbox [Mailbox Name] -RemovePicture

Hopefully someone will find this useful, I’ll add more stuff as I stumble across it.



You can diagnose the AutoConfiguration settings that Outlook will pick up from Exchange Web Services as well as the current connections that it has to CAS and Mailbox servers by simply holding down the CTRL key and right-clicking the Outlook icon in the system tray notification area like so:

Outlook Troubleshooting Options
Outlook Troubleshooting Options

The Connection Status option will also allow you to reset the connection to the Exchange servers to help with diagnosing any issues:

Outlook Connection Status
Outlook Connection Status

Useful when you’re not sure if the client is communicating with the server correctly or not and don’t fancy firing up Wireshark and trawling through packet traces.