Blog: Networking

Problem

The use of Outlook 2003 in an Exchange 2007 environment seems to result in the Out Of Office assistant being out of sync. Duplicate or old Out of Office replies are sent back to sender.

Cause

The duplicate OOF messages are sent because the legacy rule is enabled on an Exchange 2007 server - as well as the new EXCHANGE 2007 OOF rule(s).

When OOFAssistant see an interesting mapiEvent for a mailbox for the first time on an EXCHANGE 2007 server, it disables the legacy OOF rule.  After that, it does not disable the legacy OOF rule again (unless the user changes the OOF settings with OWA or Outlook 2007).

When an Outlook 2003 user turns on OOF for the very first time, it creates the legacy OOF rule (enabled).  When turning OOF off/on, Outlook 2003 leaves the legacy OOF rule in place and just changes a mailbox property to enable/disable OOF messages.  Thus, if something (say OOFAssistant) had disabled the legacy OOF rule, it remains disabled when Outlook 2003 turns OOF off and on.

The problem appears in the following situation also: [more]

• A mailbox is created on an EXCHANGE 2007 server.  OOFAssistant sees some interesting mapiEvent related to that mailbox.  OOFAssistant runs code to disable the legacy OOF rule, but since Outlook 2003 has not created one yet, OOFAssistant does nothing.
• The user turns on OOF with Outlook 2003 for the very first time.  Outlook 2003 creates the new legacy OOF rule (enabled).
• OOFAssistant processes the change to the legacy OOF rule by creating the new EXCHANGE 2007 OOF rule(s).
• Duplicate OOF messages are sent.

In addition, Out of Office replies can be corrupted by the Blackberry Enterprise server.

Solution

1. Install Microsoft Exchange 2007 SP1 - this update checks and disables the legacy OOF rule every time it encounters an interesting mapiEvent
2. and Blackberry enterprise Server 4.1.5 MR1 or later (refer to http://www.blackberryforums.com/bes-admin-corner/112250-out-office-oof-corruption-blackberry-bes-exchange-2007-a.html for an explanation of the blackberry issue that is resolved with the fix)

Other Workarounds

Workaround #1:

The problem is more likely a problem with OOF rules. OOF is actually a server side rule in user's mailbox. It may corrupt, or damaged. When this occurs, we run Outlook with the /cleanrules switch to clear out the rules and recreate the OOF rule, so everything will then come back normal.

Workaround #2:

1. Launch the MFCMapi tool.
2. Open the Mailbox of the affected user.
3. Right click on the Inbox folder and select Open Associated Contents Table.
4. Select the Message Class column and find the IPM.Rule.Message and IPM.Note.Rules.OofTemplate.Microsoft messages.
5. Before deleting the messages you can take backup of the template message the user had set for his OOF rule.
6. Delete these messages for the affected user.

Workaround #3:

Set up OOF through OWA 2007

There is a known issue with SQL Server 2005 SP2 that occurs if you have moved the system databases to another location. Specifically, the mymssqlsystemresource database. If the mymssqlsystemresource transaction log has been moved from its default location, the installer for SP2 does not recognize this. The installer places the new mymssqlsystemresource.ldf file in the same directory as the mymssqlsystemresource.mdf file regardless of whether this is where you have moved the .ldf file to. After the SP2 install, SQL Server services will not start. To fix the issue, simply copy the .ldf file from the directory where mymssqlsystemresource.mdf lives and place it in the updated location and restart the SQL Server services.

If you have multiple SQL Server instances on a server, running the service pack install in ‘default gui’ mode will only apply to the default instance.  To install to all instances at the same time, you need to expand the service pack, then run from the command line with the /allinstances tag: [more]

http://www.sqlserverclub.com/articles/how-to-upgrade-sql-server-instances-quickly-and-quietly.aspx

Here is some related info on SQL instances from MSDN:

http://msdn.microsoft.com/en-us/library/ms143531(SQL.90).aspx

I came across an issue where WSUS and Microsoft Update kept getting an error installing .NET Framework 3.0 SP1 update on Windows XP PC.  I went to add/remove programs to uninstall .NET Framework 3.0 but there was no button to uninstall it. 

I thought that something was goofed up, so I came across a .NET cleanup tool that automated a manual uninstall of all .NET versions.  After this was done, I tried Microsoft update again and it still failed during installation of .NET 3.0 SP1. 

I ran the cleanup tool again and tried manually installing each version using the direct downloads from Microsoft and installation still failed. [more]

After some more researching, I found mention that .NET 3.5 SP1 would try to install .NET 3.0 if it was not installed.  The installation of .NET 3.5 SP1 worked and I saw that .NET 3.0 SP2 was actually packaged in with it. 

I ran Microsoft Update again and verified that there were no longer any updates needed by the PC.

On Thursday, October 23 2008, Microsoft released a critical out-of-cycle security update. This update addresses a vulnerability in the Windows server service that could allow remote code execution. Microsoft has rated this vulnerability Critical for all supported editions of Microsoft Windows 2000, Windows XP, and Windows Server 2003. This vulnerability has been rated Important for all supported editions of Windows Vista and Windows Server 2008.

The update addresses the vulnerability by correcting the way that the Server service handles RPC requests. Additional technical details on the vulnerability and update can be accessed at:
http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx

As a best practice, RPC functionality should not be exposed directly to the Internet. However as a precaution, CoNetrix recommends applying the update available from Microsoft as soon as possible.

If you have any questions or need assistance with this update, please contact CoNetrix at [email protected] or call (800) 356-6568.

I had an issue with an XP workstation this week where a user could not connect to a certain dfs link in the dfs tree. The tree contained three root shares, one of those being the Apps folder. None of the PCs could map a network drive to the \\domain\Apps folder from explorer or using NET USE command. However, if the direct referral location was used (\\server\data\apps$), everything worked, so it wasn’t a permissions issue. After much troubleshooting and a couple reboots later, I came across an article regarding this issue (http://social.technet.microsoft.com/Forums/en-US/winserverfiles/thread/f64f87c2-76bd-4e0d-a34e-31fd5f321ba2/). The issue is with XP SP3, of which each computer that was having issues had installed. The issue results from a corrupted DFS link entry in AD. XP prior to SP3 would ignore it, but SP3 will not. The solution is to delete and recreate the DFS link and then purge the DFS mup cache on the client by using the following commands (dfsutil is part of windows 2k3 support tools) [more]

Dfsutil /pktflush

The Vista firewall can only apply one profile (either Domain, Public, or Private) at a time.  So if you have one network interface that Vista has identified as connected to the domain and another network interface (a VMWare interface, for example) that Vista cannot identify, it applies the most restrictive firewall profile (Public) to both interfaces.   Obviously, this can break applications if your Public profile is locked down.

In order to fix this issue, you can either: [more]

1. Disable the VMWare network interfaces if you don’t use them.  They are not needed in bridged mode.
2. Tell Vista to ignore the VMWare network interfaces when deciding which firewall profile to apply.
   • Disable the VMWARE NICs (VMNET1 and VMNET8 in my case)
   • Run regedit and go to HKLM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}
   • Here you will find a list of numbers (0000 to 0024 in my case)
   • Click through these keys until you find the one with value VMnet=the name of your VMWare NICs (\DosDevices\VMNET1 and \DosDevices\VMNET8 in my case)
   • Add the key *NdisDeviceType with a DWORD value of 1 for each NIC
   • Enable the VMWare NICS
   • While connected the Compu-Share domain and with the VMWare interfaces enabled, verify the fix worked by going to Control Panel->Windows Firewall.  The Network Location should be listed as “Domain network”.
   • Note: Some people on the Internet said that these registry keys are removed when you upgrade VMWare to a new version.  If so, you will have to add them back manually.

We recently had a customer that switched Internet service providers.  After making the switch, users were getting “sending delayed” messages from the Exchange server.  The problem turned out to be caused by mis-configured DNS settings in the Exchange 2003 SMTP service.  Some e-mails appeared to be going through fine, while others were delayed and eventually dropped.  Sometimes, messages would go through, the other person would respond, and then they’d get a delayed notification for the originally sent message.  After some e-mails that were sent to CoNetrix were completely dropped, I started looking more closely at the SMTP service configuration.  I went through every setting and eventually found some entries for the old ISP's DNS servers buried in the following location: [more]

Servers -> SERVERNAME -> Protocols -> SMTP -> Default SMTP Virtual Server -> Properties -> Delivery tab -> Advanced -> Configure

This configure allows you to specify “external DNS servers”.  Apparently, based on the name, someone thought the real “external” DNS servers should be used (instead of the local DNS service that uses the external servers as forwarders).  I removed the old ISP server entries and replaced them with the external DNS servers of the new ISP as a test.  Once I did this, e-mail started sending immediately.  I then changed the entry to the local IP of the server (so the local DNS service would be used).  Things continued to work.  Setting those DNS entries is not part of our normal server setup procedures, so I'm not sure where the DNS entries originally came from.  They may have been populated by some "wizard", so keep the SMTP DNS settings in mind if you ever have a similar problem.

I have been using an application launcher called AppRocket for years.  I have now switched to Find And Run Robot (FARR) (http://www.donationcoder.com/Software/Mouser/findrun/index.html).  It is a great timesaver to run an application launcher instead of navigating through menus or spending hours setting up special shortcuts, etc.  Here are a few features that I think make FARR superior to other methods of launching programs and documents. [more]

• It does not build an index beforehand, so it is always up to date.  You can arrange the order of the directories it searches, so the rarely used ones will be searched last.  As soon as it finds a match for what you have entered, you can launch it.
• It uses rules to determine the order matches appear, such as recently launched items get a higher rating.
• It has a plugin system and many plugins have been written, such as one to search your clipboard history, firefox/opera plugins.
• Aliases can be set up so that parameters can be passed – the selected text passed to search engine, for example.

Software from Donation Coder is free but supported by donations.