Tag Archives: Errors

Things I Didn’t Know Until Today – LastLogonTimestamp Edition

Posted by on 20/08/2012 No comments

So today I discovered that the LastLogonTimestamp attribute of an account in AD (also known as LLTS) is only updated on logon if the old value is more than 14 days in the past. That means the value can only be trusted if it is more than 14 days in the past.

This, as it turns out, is very annoying if you’re trying to do some semi-half-assed auditing. Now, you can use the LastLogon attribute, which is always up to date, but that isn’t replicated between DCs so you have to query all of them.

Note to my future self: Do not rely on LLTS for anything more recent than 14 days.

Failed To Restore Print Queue…Error 0x800706d9

Posted by on 22/02/2012 No comments

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.

NTP issues on DCs set to NT5DS

Posted by on 24/01/2012 1 comment

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.

Exchange 2010 SP2 – A Warning

Posted by on 16/12/2011 2 comments

You may remember my post a while back about issues with applying Exchange 2010 SP1 in situations where you were using Group Policy to control Powershell Execution policies. Specifically, this issue occurs because the Group Policy setting uses the WMI service to enforce the Execution Policy and as part of the Exchange install/upgrade process, the WMI service is stopped, causing the Execution Policy to revert to Restricted and the following error to pop up and the install to fail:

The following error was generated when "$error.Clear();
& $RoleBinPath\ServiceControl.ps1 EnableServices Critical
" was run: "AuthorizationManager check failed.".

Well it turns out that this still applies with Exchange 2010 SP2 in exactly the same fashion.

The (well, A) relevant KB article is here but the “workaround” is a bit half-assed to be honest and you’re much better off just disabling the associated Group Policy setting and configuring the Execution Policy locally (with set-executionpolicy) to either AllSigned,RemoteSigned or Unrestricted for the duration of the upgrade.

Why Microsoft cannot add installer logic to check for this possibility, especially given how long it’s been a potential problem, is beyond me but then I’m not an Exchange developer.

You must close all dialog boxes before you can close Exchange Management Console

Posted by on 12/07/2011 1 comment

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.

NSClient++ Errors

Posted by on 04/07/2011 3 comments

A commonly reported issue with NSClient++ is seeing the following error when trying to install the service or run the client:

“The image file c:\[Path]\nsclient++.exe is valid, but is for a machine type other than the current machine”

The cause of this issue is attempting to run the incorrect version of the client for your architecture i.e. Trying to run the 64-bit version on a 32-bit operating system. The solution, obviously, is to run the correct version.

On Exchange 2010 Retention Policies

Posted by on 27/04/2011 No comments

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 :)

Exchange 2010 EMC and Non-Existent Servers

Posted by on 27/04/2011 No comments

It would appear that the Exchange 2010 EMC isn’t particularly bright; when you launch it, it picks a CAS to connect to from AD. This is fine.

However, should that server cease to exist, by which I mean Exchange is uninstalled and it is properly decommissioned, then the EMC will continue to try and connect to it. Even after the connection fails, it’ll keep on merrily plugging away at the non-existent server, never considering that there are probably other servers it could try.

This is very annoying and seemingly very stupid behaviour. To work around it, close the EMC, fire up your registry editor of choice, locate the following key: HKCU\Software\Microsoft\Exchangeserver\v14\AdminTools\ and delete the NodeStructureSettings value. This will reset the EMC and cause it to pick a new CAS to connect to; it may also affect other settings that you’ve changed in the console.

Another option is to close the EMC, navigate to C:\users\<username>\AppData\Roaming\Microsoft\MMC\ and delete the Exchange Management Console file. This will also reset the EMC and will definitely reset any customisations you’ve made to the console.

Why you should ever have to do this is something of a mystery to me, perhaps Microsoft just never expected anyone to decommission an Exchange server once it was built.

Exchange 2010 RBAC Errors

Posted by on 10/02/2011 3 comments

Update: This turned out to be a Nagios-related powershell script running against Exchange that was being launched by a service running as LocalSystem, which didn’t have permissions to perform various tasks within Exchange. As soon as we stopped running the script the errors went away. Still no idea why the errors were popping up on servers in the Org that weren’t referenced by the task, but that’s Exchange for you.

Right, I’m throwing this out on the tiny off-chance that anyone has come across it and knows of a solution, because so far, Microsoft support haven’t and don’t.

Frequent entries in the Application logs of all Exchange 2010 Servers as follows:

(Process w3wp.exe, PID <PID>) “RBAC authorization returns Access Denied for user <Mailbox Server Computer Account>. Reason: No role assignments associated with the specified user were found on Domain Controller <Domain Controller FQDN>”

Several things.

1) Everything in <> has obviously been changed by me to remove details of my internal infrastructure, the actual errors contain real PID, account and server values. In all cases, the computer account is that of the Mailbox server, even though the error shows up on Mailbox, CAS and UM servers.

2) This is not, I repeat, not the same issue as you’ll find all over Google with a very similar error message that features a user account rather than a computer account. That one is usually caused by people not setting up permissions for their administrators properly in the ECP or broken permissions inheritance on accounts.

3) This error has survived a complete rebuild (OS and Exchange) of the Mailbox server, a re-running of the domain/forest prep tools and a couple of weeks examination by Microsoft Support. We’re currently looking at rebuilding all the other 2010 servers to see if it survives that too.

Any suggestions will be gratefully accepted.

Use Eventlogs Properly!

Posted by on 08/11/2010 No comments

Windows has a centralised logging facility for applications; the Windows Event Log. If you’re writing applications for Windows then for the love of God please use it properly.

DO create your own event message DLL(s) where appropriate to avoid your events looking like this

DO log important errors and warnings. Application failures, communication issues, invalid configuration data and the like. Things that will help administrators to troubleshoot issues that may occur.

DO make your logs intelligible to someone other than you. Not having developed the application myself, I have no way of knowing if “Invalid foo in bar. More cheese needed at 0×8003387″ means that someone’s made a typo in a config file somewhere, a firewall rule needs changing or that the application doesn’t support running during the vernal equinox.

DO throttle your logging. Don’t log the same error every second, it’s pointless, generates a lot of “noise” and – much worse – forces other, potentially useful events out of the log’s retention.

DO make your logging level easily configurable by the user and DO set a sensible default.

DON’T log every single informational or debug event that your application generates. Nobody gives a shit that you successfully checked a message queue and found it was empty; either use a Custom Event Log or a log file in the application directory if you want to record that kind of information.