I'm using Outlook 2007 to connect to Exchange 2003 under SBS 2003. All of my rules are server-side. The rules are still in Outlook 2003 format, though I'm not sure if that matters for this issue. 

Recently I used a third-party program to restore a backup to my aging MPx220 SmartPhone. Upon connecting with ActiveSync, it overwrote my Inbox, Tasks, and Calendar in Outlook and thus Exchange. Bad.

Fortunately, my daily Exchange backup with the Backup Exec 10d Exchange option had run that morning, so I was able to restore the mailbox in short order.

Unfortunately, this messed up my rules in Outlook 2007. The rules were there, and they ran fine manually, but they would not run automatically when mail was received.

Article 232585 in the Symantec knowledge base pointed me in the right direction, but was not a full solution. It recommends exporting and importing the rules. When I did that, nothing seemed to change. All the rules were there, but only a couple of them were firing automatically. 

I thought maybe I could fix the server-side rules by looking at them in Outlook Web Access (OWA). It turns out that none of my rules can be editing in OWA (apparently because OWA can't handle the "stop processing more rules" directive). What's interesting is that OWA showed me that each rule appeared twice. The export/import must have duplicated them.

This gave me the idea for the following solution:

1. Print the list of rules from OWA in case you might need to recreate them manually.
2. Export the rules from Outlook 2007 to a .rwz file on your desktop.
3. Close Outlook 2007. From the command line, run "outlook /cleanrules" to delete all your server- and client-side rules. Close Outlook again.
4. Start Outlook normally. Import the rules that you exported in step 2 above.
   

Now you should only see one copy of the each rule in OWA, and they should be triggered automatically!

I recently upgraded my XP desktop to Service Pack 3, which includes an update to Remote Desktop Client 6.1.

Today I locked a Windows Server 2003 console session at a client site, then tried later to access the console session by typing "mstsc.exe /console" from the command line. Instead of connecting to the console, I found myself dropped into a new session on the server. When I started Terminal Services Manager on the remote machine, I saw two sessions, including the console session. When I tried to remote control the console session, I got the message, ""Can't remote control session (ID 0)."

I finally found this Terminal Services Team Blog post with the explanation:

Changes to Remote Administration in Windows Server 2008

There are reasons why /console is no longer needed in Windows Server 2008. Apparently that justifies removing this functionalitiy from RDC 6.1, even when connecting to Windows Server 2003. Worse, the connection succeeds but "silently ignores" the /console switch.

Fortunately, there is a workaround:  use the new /admin switch instead.

Both the application-specific Help file and the Windows XP Help and Support Center still list the missing /console switch and do not mention the /admin switch. Note to Microsoft:  if you're going to "silently" remove functionality, at least update the documentation!

I had a customer some time ago who always spelled out my full company name when sending  me email. I finally registered mcbsystems.com so I could receive her emails.

Since then I've implemented Exchange 2003 (under SBS 2003), but apparently I never tested the domain alias until I was setting up Postini. It turns out that Exchange was bouncing messages sent to the domain with a "550 5.7.1 Unable to relay" message.

My situation  pretty much matches the second "class" of SMTP domain in this Microsoft Knowledge Base article:

Setting up SMTP domains for inbound and relay e-mail in Exchange 2000 Server and in Exchange Server 2003

Howver, whereas the article suggests changing the SMTP connector to allow messages to be relayed to this domain, I discovered another option. If I go to Recipient Policies > Default Policy > E-Mail Addresses (Policy) tab, create a policy @mcbsystems.com, and check the box to the left that causes it to auto-generate the address for new Active Directory users, relaying works. If you don't check the box for auto-generating addresses, relaying only works if it is set up in the SMTP connector. I'm not sure what auto-generation of addresses has to do with relaying, but I thought I'd better write this down before I forget it!

Time to Move On

 I've been pretty happy with BlogEngine.NET 1.1 for the last ten months, but I don't want to get too far behind, so I decided today to update to the current release, BlogEngine.NET 1.3.1.

This procedure is specific to my installation, but it may give you some guidance on how to upgrade your installation. As background, my setup is as follows:

• I run my own web server under Small Business Server 2003.
• IIS is set up with all .NET 2.0 applications sharing an application pool called NET20AppPool.
• I set up a new application for blogs called, uh, blogs. This maps to a virtual directory called inetpub\blogs.mycompany.
• Inside the blogs.mycompany folder is a subfolder containing the actual blog application. I call this mark.
  

Getting Ready

I watched Al Nyveldt's installation video for a helpful refresher on how to set up BlogEngine.NET. I decided to get the base install of version 1.3.1 working first, then to copy in the settings and posts from my previous installation.

Do the Upgrade

Follow these steps to upgrade from BlogEngine.NET 1.1 to 1.3.1:

1. Download and unzip the web installation file. Rename the unzipped folder to mark.
2. In IIS, stop the blogs application and the DOTNET20AppPool.
3. In Windows Explorer, under inetpub\blogs.mycompany:
   1. Rename mark to mark.old.
   2. Move the unzipped mark folder to inetpub\blogs.mycompany folder.
   3. Remove any existing permissions from mark. Go to Advanced to inherit permissions from inetpub\blogs.mycompany.
   4. Go to the App_Data folder and give NETWORK SERVICE Modify permission. (I have NET20AppPool set up to use the NETWORK SERVICE account.)
   5. Edit mark\robots.txt to point to the correct path.
   6. In the App_Data folder, copy settings.xml to settings.orig.1.3.1.xml.
   7. In the old App_Data folder, use Microsoft Word or SourceSafe to display the differences between Settings.orig.1.1.xml and Settings.xml. In the new App_Data folder, make the corresponding changes to Settings.xml.
   8. In the new App_Data folder, delete the contents of the log, pages, and posts folders.
   9. Copy the following files and folders from old App_Data folder to the new App_Data folder, overwriting when necessary:
      
      blogroll.xml
      categories.xml
      roles.xml (wasn't present in 1.1 but probably need to copy when upgrading past 1.3.1)
      users.xml
      files\*.*
      log\*.*
      pages\*.*
      posts\*.*
      
      
   10. Copy the old themes\mytheme folder to the new themes folder.
4. In IIS, start the DOTNET20AppPool and the blogs application.
5. Open the blog in a browser.

Test and Debug

When opening the blog in a browser, you may encounter errors if underlying technology has changed. Check the server's event log if you get an error. On this update, I found that Utils.SafeMail was no longer there. So in mytheme\sidepanel.ascx, I copied in the new alternative (which uses a contact form) from the Standard theme. The required contact.aspx form was already there; I edited it to put the labels and fields in a table for a nicer look. I also edited RecentPosts.cs to add a space before the Comments and Ratings labels to keep them from running together.

You should check the Control Panel > Settings tab to see if there are new settings that you want to configure. I chose to uncheck Enable post ratings for now. I also changed the avatar processor from Combination back to Gravatar. This got rid of the colorful but squirrelly icons that must be coming from Monster when the person has no avatar.

By the way, I initially formatted the above procedure in FrontPage 2003, complete with a, b, c, d, etc. for the sub-points. This created an <ol type="a"> tag. For some reason, BlogEngine.NET strips out the type attribute when I paste in the HTML, leaving incorrect sub-point numbering. No fix for that now.

Fix the Theme

I wound up having to re-do most of my theme modifications, which weren't too extensive:

1. Copy the contents of the current themes\Standard folder to the themes\mytheme.
2. In site.master, add my "customized by" note to the footer.
   
3. In sidepanel.ascx, copy in the previous About Me table. (See the note above about using the new contact form instead of Utils.SafeMail.) Remove a few sectiosn I don't use (Calendar etc.). Make the Archive header a hyperlink to thew new archive.aspx page. Copy in the previous Disclaimer text.
4. Modify style.css to use the colors used in the old version. (There are lots of new styles, so you can't just use the old version.) Add the following styles to the Side Panel section to handle a hyperlink (now that the Archive header is a hyperlink):

		#sidepanel .box h1 a {
	color: #999999;
	text-decoration: none;
	}
	#sidepanel .box h1 a:hover {
	text-decoration: underline;
	color: #003399;
	}
	

Problem

I have a workstation running Windows XP SP2 on an SBS 2003 domain with Exchange. Yesterday I upgraded it from Office 2003 SP3 to Office 2007 SP1.  All security patches have been applied.

When logged on to this machine as an administrative user, Outlook crashes 100% consistently whenever I exit Outlook. Starting as "outlook.exe /safe" did not help. Running Office Diagnostics did not help.

Here is some information from the error that is sent to Microsoft:

Error signature
AppName: outlook.exe
AppVer: 12.0.63000.5000
appStamp: 4760725d
ModName: dccmsp32.dll
ModVer: 10.0.2000.929
ModStamp: 39d4133c
fDebug: 0
Offset: 00005346

Exception Information
Code: 0xc0000005
Flags: 0x00000000
Record: 0x0000000000000000
Address: 0x0000000010005346

The faulting module, dccmsp32.dll, is part of WinFax Pro 10.03. Disabling the Outlook integration on the WinFax side and the Outlook side did not solve the problem. 

Solution 

I eventually found this Symantec post:

How to integrate WinFax PRO 10.02 and Outlook 2002 on a limited basis
http://service1.symantec.com/support/faxprod.nsf/docid/2001110911391704

In the end, I wound up following the instructions at the very end of that document ("If the problems persist..."):  saving my Winfax data and cover subfolders, uninstalling WinFax, doing a Custom reinstall (deselecting External Phonebooks and send fax by email), copying my data and cover subfolders back, and renaming these four files:

C:\Program Files\Winfax\Wfxext.dll
C:\Program Files\Winfax\Wfoladin.dll
C:\Windows\system32\Dccmsp32.dll
C:\Windows\system32\ Dccwfp32.dll

After that, Outlook exits with no problems, and WinFax works by starting the Message Maanger (not the Controller).