October 2008

Cannot Add a Site to Trusted Sites

Friday, October 31, 2008

I ran into a weird problem today with a Windows Server 2003 SP2 server, where I could not add a site to the Trusted Sites zone. The error I got was, "There was an unexpected error with your zone settings. Unable to add this zone."

To fix the issue, enable Internet Explorer Enhance Security Configuration in Add/Remove Windows Components, add the desired site to the Trusted Sites zone, and then disable Internet Explorer Enhance Security Configuration again. That seems to fix the corruption in the Trusted Sites zone information. Future sites can then be added without issue.

Getting Windows Mobile to Work with Exchange 2007 Using POP3/IMAP4 and SMTP (Part 2)

Saturday, October 25, 2008

This is part 2 of my series, where I show you how to configure Windows Mobile to send and receive email from Exchange 2007 using IMAP4 and SMTP.
Part 1, where we configured Exchange 2007, can be read here.

Now that Exchange 2007 is configured, we need to configure a new email account in Windows Mobile. How you do this depends on the version of Windows Mobile on your device, but the essential steps are as follows:

Enter your email address and password to access the new account
Select Internet e-mail from the dropdown box for Your e-mail provider
Enter your name as you want it to appear to recipients and choose an account display name on the device (i.e., IMAP Email)
Enter the FQDN for the Exchange 2007 server that holds the Client Access (CAS) role (i.e., cas.mydomain.com) for the Incoming mail server.
Choose IMAP4 as the Account Type
Enter your account logon (domain\username) for the User Name and enter the network password
Enter the FQDN for the Exchange 2007 server that holds the Hub Transport role, followed by :587 (i.e., smtp.mydomain.com:587) for the Outgoing (SMTP) mail server. See the figure above. If you don't follow the FQDN with :587, the Windows Mobile device will use the standard port 25 for SMTP communication.
Select Outgoing server requires authentication
Under Advanced Settings, select both the Require SSL for Incoming e-mail and Require SSL for Outgoing e-mail checkboxes to encrypt the traffic between the Windows Mobile device and Exchange 2007
Configure your Automatic Send/Receive schedule

Important Note: You must enter the FQDN:587 correctly the first time for the Outgoing (SMTP) mail server field. You cannot edit it later once you've clicked off that field -- if you do, Windows Mobile will still use port 25. This seems to be a bug in Windows Mobile 6.1 and may happen in other versions, as well. If you don't enter it correctly the first time, you will either need to cancel the setup wizard and start over again or delete the email account and recreate it.
Now test your new settings by synchronizing the mail account and test sending
an email. If you get an error saying,

Message not sent. The message 'Test email' was not sent and has been moved to the Drafts folder. The server returned the following error message:
550 5.7.1 Unable to relay

It means that the Windows mobile device is trying to send SMTP email over port 25 through your Exchange server to a remote address, which is relaying. Delete the account you just created and do it again, making sure to enter :587 after the FQDN of the SMTP server.
I hope this two-part series helps you get IMAP and SMTP working properly between Exchange 2007 and your Windows Mobile device!

Getting Windows Mobile to Work with Exchange 2007 Using POP3/IMAP4 and SMTP (Part 1)

Friday, October 24, 2008

This is the first of a two-part article that describes how to enable Windows Mobile devices to receive email from Exchange 2007 using IMAP4 and send email using SMTP.

As you probably know, Windows Mobile can only have one connection agreement with Exchange at a time. That means that if you want to access additional email accounts you must use POP3 or IMAP4 for incoming email and SMTP for outgoing email on your device.

In part 1, I will describe how to set up IMAP4 and SMTP client email submission in Exchange 2007. Part 2 will describe how to configure the Windows Mobile client.

Configuring IMAP4 in Exchange 2007
POP3 offers simple email retrieval services from a user's Inbox in Exchange. IMAP4 offers a few more extensive features, including access to all the folders in the user's mailbox. Neither of these services are enabled in Exchange 2007 by default. To enable POP3 or IMAP4 (usually one or the other), simply change the appropriate service from Manual to Automatic on your Exchange 2007 Client Access server (CAS) and then start it. In this article I will be using IMAP4 for Windows Mobile access.

The next step is to configure the logon authentication mechanism for IMAP4. I strongly recommend using TLS to secure logons so that usernames and passwords are not transmitted in plain text.

Open the Exchange Management Console (EMC)
Navigate to Server Configuration, Client Access and view the POP3 and IMAP4 properties of the CAS
Double-click the IMAP4 protocol and select the Authentication tab
Select Secure Logon. A TLS connection is required for the client to authenticate to the server.
Select the appropriate X.509 certificate to use and click OK to close the properties window

Configuring SMTP Client Submissions in Exchange 2007
Now we need to configure the Exchange 2007 Hub Transport (HT) server to accept (receive)inbound SMTP connections from clients.

Open the Exchange Management Console (EMC)
Navigate to Server Configuration, Hub Transport and select the HT server
Click New Receive Connector from the Action pane
Give the new Receive Connector a name such as, "Mobile Clients"
Select Client as the intended use for this receive connector and click Next
Click Next to allow all remote networks to use this receive connector
Click New to create the new Receive Connector
Now open the properties of the Mobile Clients connector
Click the Network tab and notice that the port the connector uses is 587
Click the Authentication tab. Ensure that Transport Layer Security (TLS), Basic Authentication, Offer basic authentication only after starting TLS, and Integrated Windows Authentication are checked.
Click the Permissions Groups tab. Ensure that only Exchange users is checked and click OK to close the properties window.

Name Resolution and Port Forwarding
The FQDN of the CAS (i.e., cas.mydomain.com) and the HT server (i.e., smtp.mydomain.com) must be resolvable from your Windows Mobile device on the Internet. The CAS must also accept IMAP4 requests and the HT must accept SMTP submissions from your Windows Mobile device. This may require you to configure port forwarding from your external firewall. You will need to forward TCP port 143 for IMAP4 to the CAS and port 587 for client SMTP message submission to the HT server.

Port 25 is fast becoming the port used exclusively for server to server SMTP traffic and port 587 is becoming the standard for client to server SMTP traffic.

So far, we have configured Exchange 2007 to allow secure IMAP4 and SMTP client access. In part 2 of this series I will discuss how to enable IMAP4 and SMTP access to Exchange from a Windows Mobile device.

Fix for 0x8024400E Errors on WSUS Clients

Monday, October 20, 2008

I've seen this happen with two customers over the past few weeks, so I figure it might be prevalent enough to blog about it.

Symptom:
Some, but not all, WSUS clients begin to fail when checking for updates. The %windir%\WindowsUpdate.log file shows errors such as:

WARNING: SyncUpdates failure, error = 0x8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200

WARNING: PTError: 0x8024400e

WARNING: Failed to synchronize, error = 0x8024400E

WARNING: WU client failed Searching for update with error 0x8024400e

According to the Comprehensive List of WSUS Codes page hosted on this blog, the 0x8024400e error means "SUS_E_PT_SOAP_SERVER: The message was OK but server couldn't process at the moment. Same message *may* succeed at a later time." Huh? I already took a shower this morning! What's with this SOAP business?

The Fix:
This problem is due to problem with a recent revision to the Office 2003 Service Pack 1 update on the WSUS server. It results in some WSUS 3.X servers syncing that revision to an inconsistent state. When computer with products related to Office 2003 communicate to one of these WSUS servers, the web service is unable to process the approvals resulting in detection failure.

In order to reset the approvals to a consistent state on the WSUS server, follow these steps from the WSUS Administration Console:

Find the 'Office 2003 Service Pack 1' update in the updates list. This may involve changing the Approval and Status filters in the update UI (set the Status to "Any" and the Approval to "Declined" -- if you don't see it then set the Approval to "Any except Declined"

Perform the following steps:

First, make sure the update is declined. If the update is not yet declined, right-click on the update and decline it.

Next, approve the update:

Right-click on the update and select the 'Approve...' option in the context menu.

In the 'Approve Updates' dialog that opens, just click 'OK'. Dismiss the 'Approval Progress' dialog that appears.

Next, decline the update.

Right-click on the update and select the 'Approve...' option in the context menu.

In the 'Approve Updates' dialog that opens, just click 'OK'. Dismiss the 'Approval Progress' dialog that appears.

The computers that were failing detection will now successfully complete detection against the server and receive any applicable updates.

Note: If you have a hierarchy of WSUS servers, these steps must be performed on each server, starting with the top-level server. If one of the servers is a replica child, one must first change it to be autonomous, then perform the steps above, then change it back to being a replica. This can be done from the Options/Update Source and Proxy Server Dialog.

MDOP Charter Member

Monday, October 20, 2008

I passed the 70-656 Microsoft Desktop Optimization Pack, Configuring exam this weekend. This exam covers the value-add features for Microsoft customers who have Windows Vista Enterprise with Software Assurance.

Windows Vista Enterprise and the Microsoft Desktop Optimization Pack (MDOP) provides powerful technologies that will help you secure, efficiently manage, and lower the costs of your organization's desktop infrastructure.

MDOP Dynamic desktop management technologies will enable you to control your software assets, simplify desktop deployments, and create a optimized infrastructure with centrally managed services:

Microsoft Desktop Optimization Pack for Software Assurance includes the following features and enhancements:

Microsoft SoftGrid Application Virtualization (formerly Softricity SoftGrid) transforms applications into network-available services
Microsoft System Center Desktop Error Monitoring provides IT with awareness and insight into application and operating system failures
Microsoft Asset Inventory Service (formerly AssetMetrix) delivers a comprehensive view of your customers' enterprise desktop software environment
Microsoft Diagnostics and Recovery Toolset (formerly Winternals Administator’s Pak) accelerates desktop repair
Microsoft Advanced Group Policy Management (formerly DesktopStandard GPOVault) enhances administrators' control over enterprise desktops
Enterprise Desktop Virtualization minimizes Application to OS Compatibility Issues

So THAT'S the problem...

Monday, October 13, 2008

Good thing we have logs to tell us when something's CRAPI.

Fix for Large Framework.log files

Thursday, October 9, 2008

The WMI service maintains text log files for all operating systems earlier than Windows Vista and Windows Server 2008. These log files are stored in the %SystemRoot%\System32\WBEM\Logs folder. The log files include:

Wbemcore.log

Wbemess.log

Mofcomp.log

Wmiadap.log

Wbemprox.log

Framework.log

Winmgmt.log

Most of these log files are configured to automatically wrap every 64KB. When the log file reaches this limit, it is renamed to logfile.lo_ and a new log file is created. Unfortunately, this does not happen with the Framework.log file - it will continue to grow indefinitely. This came to light recently at a client site when the backup team noticed that this file was taking a very long time to back up on Exchange servers. The Framework.log files on these servers exceeded 800MB.

Microsoft wrote a TechNet support article, "The Framework.log file grows larger than 64 KB when you use WMI on a Windows Server 2003 or Windows XP computer," which explains that this is due to permissions problem with the Network Service. As the article explains, the fix is to grant the Network Service account the Delete right on the %SystemRoot%\System32\WBEM\Logs folder.

Here's how to do this for all machines in the domain using Group Policy:

Edit the appropriate Group Policy object for the managed computers. I used the Default Domain Policy.
Navigate to Computer Configuration, Windows Settings, Security Settings, File System
Right-click File System and select Add File...
Navigate to the %SystemRoot%\System32\WBEM\Logs folder and click OK. A security window will appear.
Add the LOCAL SERVICE and NETWORK SERVICE accounts, giving both accounts only Read and Write permissions.
Click the Advanced button.
Clear the "Inherit from parent the permission entries that apply to child objects" checkbox.
Select the NETWORK SERVICE account and click Edit.
Check Delete under the Allow column and click OK. Repeat for the LOCAL SERVICE account.
Click OK four times to close all the dialog boxes.

The new security settings will be enforced on target computers on the next Group Policy refresh. After that, the large Framework.log file will be renamed to Framework.lo_ and a new Framework.log file will be created. Once that new logfile grows beyond 64KB it will replace the large file.

Unlocked Workstation

Wednesday, October 8, 2008

I found this great graphic at http://www.unlockedworkstation.com/.

Next time you come across an unlocked workstation, just open a browser on it and go to the website. Don't forget to lock the workstation when you're done.

Fix for "Could not start the Automatic Updates service on local computer"

Monday, October 6, 2008

You may find that the Automatic Updates service on Windows XP is stopped with the following error:

Could not start the Automatic Updates service on local computer. Error 0×80004015: The class is configured to run as a security ID different from the caller.

This can happen when Windows XP clients attempt to start the Automatic Updates service and is due to a permissions issue. The quickest and the easiest solution would be to reset the permissions for the Automatic Updates service on the client and then start the service.

To display the current permissions of the Automatic Updates service and fix them:

Click Start, Run and type “cmd” to launch the Command prompt
From the command prompt, type: SC sdshow wuauserv
The output will look like: D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)
Now, reset the permissions as follows from the command prompt (single line, wrapped for clarity):
SC sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

We can now start the service and try to detect the Automatic Updates from the command prompt:

C:\>wuauclt.exe /detectnow

This should fix the problem.

Microsoft Chats with Hyper-V Unleashed Authors

Monday, October 6, 2008

A chat with the authors of Hyper-V Unleashed

Last week I attended the Windows 7 TAP Summit (TAP = Technology Adoption Program) in Redmond, WA. I'd love to tell you about all the cool things in store for Windows 7, but then I'd have to kill you.

While I was there, co-author Rand Morimoto and I were interviewed at the Microsoft campus about our book, Windows Server 2008 Hyper-V Unleashed.

Pages