Microsoft has launched the Group Policy Diagnostic Best Practices Analyzer (GPDBPA) to detect & diagnose problems and collect data about an environment’s Group Policy configuration. For example, you can use this tool to analyze a Group Policy configuration for the following purposes:
To search for common configuration errors (policy not functioning as expected, logon/startup delays)
To discover and to diagnose problems (security risks, services running, slow links)
Some interesting facts on running Exchange Server 2007 on the upcoming RTM version of Windows Server 2008.
Running Exchange Server 2007 RTM on Windows Server 2008 RTM is not supported
You will need to upgrade to Exchange Server 2007 Service Pack 1 if you want to run Exchange 2007 on Windows Server 2008 RTM
You can’t install Exchange Server 2007 Management Tools on Windows Vista unless you have Exchange Server 2007 SP1
If you already have Exchange Server 2007 installed on Windows Server 2003:
You CANNOT upgrade Windows Server 2003 to Windows Server 2008 on a computer running Exchange Server 2007 and then upgrade to Exchange 2007 SP1
You CANNOT upgrade Exchange Server 2007 to Exchange Server 2007 SP1 on a computer running Windows Server 2003 and then upgrade to Windows Server 2008
Yikes! So how are you going to upgrade anyway? Here’s the answer: you need to build a fresh Windows Server 2008 machine and install Exchange Server 2007 SP1 on it. (Ouch!)
Clustered Mailbox Servers: Due to immense differences in Windows Server 2008 clustering from Windows Server 2003, you CANNOT do a rolling upgrade of an Exchange Server 2007 cluster. The only way out is to build a fresh failover cluster with Windows Server 2008 running on all nodes and then use Move Mailbox to migrate data to the new cluster. (Ouch again!)
Early adopters of Exchange Server 2007 looking to also early-adopt Windows Server 2008 may now find themselves slightly challenged, given all the above parameters.
If you have Exchange Server 2003 installed on a domain that contains Windows Server 2008 RODCs (Read Only Domain Controllers):
Do NOT force Exchange Server 2003 to use RODCs or ROGCs. Not supported and ‘unexpected’ behaviour ‘expected’.
Exchange Server 2003 when in the default “auto” mode (i.e. set to automatically use any available DC) will not try to use an RODC or ROGC.
If your domain account keeps getting locked all by itself for no particular reason, its probably because you ‘saved’ your password somewhere while accessing a resource. You have since then, changed the password, but Windows (or another application) still remembers your old (cached) password and uses it to authenticate.
You may have entered your password and not thought much about it — it could be that shared folder or printer you were trying to access last month. Or it could be the password you entered for authenticating to the proxy while you logged in locally to your PC or on another machine and decided to browse the internet. It could even be entered in the browser while you logged in to the corporate portal whilst not logged in to the domain.
If this is the case, you can clear all the stored passwords on a Windows machine by typing the following command:
rundll32.exe keymgr.dll, KRShowKeyMgr
Or in Windows XP, you can use the Stored Passwords option within the Users applet in Control Panel. Remove all the stored credentials listed there and you should be fine. Also note that it saves your MSN Passport account password here as well!
Another reason for a lockout could be a service or application or scheduled task that you have configured to use your domain password while starting or performing an operation. Once you change your password, the previously saved password will not work and this results in a lockout.
One of my web servers running IIS 6.0 said this to me when I tried to open the Internet Information Services MMC console. It just wouldn’t let me connect to the server via the MMC console. The web sites hosted on the server were available merrily though.
All i had to do to bring the IIS console back to its working state was to restart the IIS Admin service and re-open the IIS MMC console. I guess IIS just needed a little kick to get back to work again.
Update: On 19 Dec, 2007, Microsoft released a hotfix that addresses this issue.
If you’ve been using Windows Server 2003 for sometime and feel that the classic interface is kind of boring, you can make it look like Windows XP.
Open the ‘Services’ MMC snap-in and change the properties of the “Themes” service. Change the startup type to “Automatic” and “Start” the service.
Now, go to Control Panel and open the “Display” applet. Open the ‘Appearance’ tab and in the drop down box there, you will find the ‘Windows XP’ theme!
The SYSTEM account is an internal account used by the Windows operating system that is similar to the administrator account, and has access to all resources, but cannot be fully managed by the user. The SYSTEM account is used internally by the OS for tasks like starting services and running processes.
There is, however, a way by which a normal user can execute commands or start processes in the context of the SYSTEM account. I’ve written an article about it on my website: “How to run a command in the context of the SYSTEM account“
I found this great piece of information on the TechNet website, that’s worth posting here. It’s an explaination on how domain controllers check passwords during authentication. I’ve re-written it in my own words to make it dummy-friendly (I like it that way!).
1. The client computer sends the user logon information (user account name and a crypto hash of the password) to the ‘nearest’ domain controller.
2. DC tries to verify the password. If it works, great! let the client know he’s in. If it did not work, either due to ‘wrong password’, ‘expired password’, ‘password must change on next login’, or due to ‘account lockout’, the domain controller forwards the authentication attempt to the PDC emulator. Since PDC Emulator is always notified whenever a DC changes a password, the PDC emulator will always have the latest password for any user at any given point of time. Hence, the authenticating DC passes the logon info to the PDC Emulator (just in case the authenticating DC doesn’t have latest password yet).
3.PDC emulator retries the authentication. If the PDC emulator operations master rejects the bad password, the password is definitely wrong! The PDC emulator operations master increments the badPwdCount attribute for that user object. The PDC is also the authority on the user’s password validity.
4. PDC Emulator informs the authenticating DC that the password didn’t work.
5. The authenticating domain controller also increments its copy of the badPwdCount attribute for the user object.
6. The authenticating domain controller then sends a response to the client computer that the logon attempt did not work.
As long as that user, program, or service continues to send bad passwords to the authenticating domain controller, logon attempts that failed because of an incorrect password continue to be forwarded to the PDC until the threshold value for incorrect logon attempts is reached (as per your Password Policy). When this occurs, the account is “locked out”.
As of July 10, Microsoft has stopped supporting Windows Server 2003 installations where at least Service Pack 1 has not been installed.
This is part of Microsoft’s Support Lifecycle policy. However, if you have a Windows Server 2003 installation that you cannot upgrade to SP1 due to technical reasons, they will continue supporting you for some more time if you ‘buy’ extended support.
Microsoft has also stopped supporting SQL Server 2000 SP3a as of July 10. So if you have SQL Server 2000 SP3a on your servers, you will need to upgrade to SP4, if you haven’t already!
ISA Server 2004 Service Pack 1 stopped getting support since April 10, 2007. Hope everybody installed Service Pack 2.
The other day, I found an article on the Microsoft Support KB, that was written for Windows 2.x and 3.x. It’s worthwhile noting that Microsoft supported Windows 3.1 for almost 10 years after its release. True story.
So you opened ADSIEDIT and checked the LastLogon attribute for a user, expecting a decently formatted date and time – and instead – found something like this: 128271382742968750.
This is the Windows NT time format. Before you jump out of your chair, lets find out what this actually is. Believe it or not, the lastLogon attribute is stored as the number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601! (Umm.. no, I don’t know why!)
So how do we convert the LastLogon value to human-years? You don’t need to pull your hair out, you can use this command:
w32tm /ntte [time in NT format] For instance, if we want to convert 128271382742968750:
To add a twist in the tale, notice that the date/time in NT Time Format is stored in GMT time. Since I am in the GMT +3:00 timezone, w32tm first listed the original value and added +3:00 to it to give me the output in my local time.
Another twist: Active Directory does NOT replicate the LastLogon attribute across domain controllers. So in order to get an accurate value, you need to obtain the LastLogon value for the same user from all your domain controllers and accept the value that is highest.
So you went ahead and installed Windows Server 2003 Service Pack 2 on your Exchange 2003 cluster because it’s a “good thing” (Not that service packs are not good things, they really are!).
Everything went well until all of a sudden, your users report that they can’t access their mailboxes through OWA. They complain that they get the dreaded “500 – Internal Server Error” message in their browsers.
Its time to dig into the Microsoft Knowledge base. KB article 841560 suggests that you install Exchange Server 2003 Service Pack 1 on your cluster and install hotfix 841561.
And then… you should find your problems melting away.
