Blog

There is a limit on how many rules you can create in Outlook.  This limit is actually based on how much space the rules take up.  The error message says “"There is not enough space on the Microsoft Exchange Server to store all of your rules", even though there is plenty of space on the drive, in the Exchange databases, etc.  According to http://support.microsoft.com/kb/241325, this is a limitation and applies to Exchange 5.0 through Exchange 2003 and Outlook 97 through Outlook 2002.  It looks like Exchange 2007 and Outlook 2007 are not affected.  That article has a few (virtually useless) pointers on how reduce the amount of space the rules take up.

Note: There is a followup to this post that provides more details and instructions on how to increase the number of rules allowed in Exchange 2007.

Whilst troubleshooting an issue with a server, it was noticed that the link from one of the interfaces which should have been connecting at gigabit speed, was only connecting at 100 Mbps.  Both the server interface and switch interface were set to autonegotiate.  The server interface was reset, but it did not fix the problem.  A new cable was installed and VOILA!  Gigabit speeds.  Upon examination of the removed cable, which was a premade cable, it was noticed that two wires were switched.

I believe that after some Microsoft Update for Vista that it somehow turned off my ability to hibernate my laptop.  I found that hibernation in Vista can be turned off and on from the command line using “powercfg /h off” or “powercfg /h on”.  After I turned it on, I was able to see the Hibernate option in the start menu without rebooting.

When allowing SQL traffic to flow across an ISA server its good to know what the ports it uses are for. SQL primarily uses two ports: 1433 (the default sql port) and 1434 (the sql browser service’s port). If you specify that you want to connect to a named instance then the traffic will first be sent over port 1434 to the sql browser service. Then the sql browser service will send back the port number that the named instance is on. Finally your application will try to talk over this port that was given to it by the sql browser service.  So, one way to get around this when going through an ISA server is to setup a publish rule to listen on 1433 (the default instance for sql) and have it forward the packets over whatever port you are using for the named instance. You must remember though, if doing this not to specify the named instance in your application’s config or else it will try to contact the browser service over 1434.

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

A Nevada Law that took effect in October will require all businesses to encrypt personally-identifiable customer data, including names, and credit-card numbers, that are transmitted electronically.  Companies in Nevada that suffer a security breach, but comply with the new law would cap their damages at $1,000 per customer for each occurrence; however, those that do not comply would be subject to unlimited civil penalties.

http://online.wsj.com/article/SB122411532152538495.html

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.