DNS Fail Over and System Monitor

A Restart from a Previous Installation is Pending

Another Exchange 2010 Installation with some Pre-Requisite check items and the following error is encountered... " A Restart from a Previous Installation is Pending "

This seems to occur when Windows Updates do not close out updates properly and when using Server Manager to automate the load of Exchange 2010 pre-reqs.

Microsoft Exchange Server setup cannot continue because a restart from a previous installation or update is pending.

The Exchange Server Analyzer reads the following registry key to determine whether a system restart is required after installation or removal of a software update such as a security update, critical update, or hotfix.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile

The Exchange Analyzer also checks the following registry key to determine whether a previous software update installation was not completed and the system must be restarted to finish the installation.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

** Note: The above is most common - just delete the contents of the key and "retry" the Exchange 2010 Setup process.


The Exchange Analyzer displays an error message if one of the following conditions is true:.

• The value of the UpdateExeVolatile registry key is anything other than 0.
  
• The PendingFileRenameOperations registry key has any value.

To delete the orphaned PendingFileRenameOperations registry key

1. Open a registry editor, such as Regedit.exe or Regedt32.exe.
   
2. Navigate to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\
   
3. In the right navigation pane, right-click the PendingFileRenameOperations key and select Delete.
   
4. Close Registry Editor.

See original TECHNET Link for additional information:

http://technet.microsoft.com/en-us/library/cc164360%28v=exchg.80%29.aspx

Google Apps Status Dashboard Link

In light of a recent Postini outage for a client, we scrambled looking for some status from Google regarding the potential outage or problem. After some searching the following link was discovered which provides realtime status access to the Google apps, of specific interest was Postini.

Google Apps Status Dashboard Link
http://www.google.com/appsstatus

Note: If you click on the Postini status for the date of interest you will be able to get specifics of the outage. This recent outage occured on 3/25 at 4:30pm through approximately 8:30pm


Landon Desk with Hutch, Oak OM04616 (Google Affiliate Ad)

A Recent issue occured where a user could not add Delegates to their Outlook for Calendar/Contact sharing. Upon research it appeared that an additional right was required to the users' AD account to allow them the ability to "Write" their own personal information within AD. We are not sure why this is not enabled by default but will provide an update once it's reached. See below Microsoft Support Article which explains and provides an immediate resolution to the issue;

"The Delegates settings were not saved correctly" error when you try to add a delegate in Outlook Clipped from: http://support.microsoft.com/kb/2593557?wa=wsignin1.0%2cwsignin1.0

Expand all | Collapse all

Symptoms

When you use Microsoft Outlook to add or to remove a delegate, the delegate is not added or deleted. Additionally, you receive the following error message:

The Delegates settings were not saved correctly. Unable to activate send-on-behalf-of list. You do not have sufficient permission to perform this operation on this object.

Back to the top | Give Feedback

Cause

When you add a delegate, Outlook also tries to grant "send on behalf of" permission to the delegate by default. This permission is written to the publicDelegates attribute of your user object in Active Directory.

The issue that is described in "Symptoms" can occur for either (or both) of the following reasons.

• The global catalog (GC) server to which your Outlook client is connected is not local to your domain.
  
  If your Outlook client is connected to a GC that is not local to your domain, the publicDelegates attribute cannot be written to your user object in Active Directory.
• The SELF object does not have the Write Personal Information right on your Active Directory user object.

Back to the top | Give Feedback

Resolution

 

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756  How to back up and restore the registry in Windows

Outlook can be configured to enable you to add delegates without requiring you to grant the "send on behalf of" permission. 

To have us configure Outlook to enable you to add delegates without requiring you to grant the "send on behalf of" permission, go to the "Fix it for me" section. If you prefer to do this yourself, go to the "Let me fix it myself" section.

Fix it for me

To configure Outlook to enable you to add delegates without requiring you to grant the "send on behalf of" permission automatically, click the Fix this problem link. Then click Run in the File Download dialog box, and follow the steps in this wizard.

 Fix this problem
Microsoft Fix it 50900

Note This wizard may be in English only. However, the automatic fix also works for other language versions of Windows.

Note If you are not on the computer that has the problem, you can save the automatic fix to a flash drive or to a CD so that you can run it on the computer that has the problem.

Let me fix it myself

To configure Outlook to enable you to add delegates without requiring you to grant the "send on behalf of" permission yourself, follow these steps:

 

1. Exit Outlook.
2.  Start Registry Editor. To do this, use one of the following procedures, as appropriate for your situation.
   
   Windows Vista

 

1. Click Start, type regedit in the Start Search box, and then press ENTER.
2. If you are prompted for an administrator password or for confirmation, type the password or click Continue.

Windows XP

1. Click Start, and then click Run.
2. If you are prompted for an administrator password or for confirmation, type the password or click Continue.

• Locate and then click the following registry subkey:
  
  
      HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\PreferencesIf you use policies, click the following subkey:
  
  
  

      HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\x.0\Outlook\Preferences
  
  Note: x.0 in the above registry key represents your Outlook version. Please use one of the following values.
  
  Outlook 2010: 14.0 
  Outlook 2007: 12.0 
  Outlook 2003: 11.0
• After you select the subkey that is specified in step 3, click New on the Edit menu, and then click DWORD Value.
• Type IgnoreSOBError, and then press Enter.
• Right-click IgnoreSOBError, and then click Modify.
• In the Value data box, type 1, and then click OK.
• On the File menu, click Exit to exit Registry Editor.

After you add the registry value, you can add a delegate without having write permissions to your own user object on the global catalog server. When you do this, a message that resembles the following message is logged in the Windows Application event log to help track the event:

Source: Outlook
Category: None
Event ID: 27
Type: Error
User: N/A
Computer: computer_name

Description:
SOB error ignored

More Information

The "send on behalf of" permission is not needed for meeting-related messages. Microsoft Exchange Server specifically does not require that you have "send on behalf of" permissions to send a meeting request on behalf of another user. Therefore, even without the "send on behalf of" permission, delegates can successfully send meeting requests on behalf of the calendar owner.

However, when you use a delegate that does not have the "send on behalf of" permission to send a non-meeting-related message on behalf of the owner, the operation fails. For example, if a delegate tried to send an informational message "from the boss," that operation would fail. This is because the "send on behalf of" permission was not successfully granted.

If you want to grant another user the "send on behalf of" permission on your mailbox, you can do this on the Exchange Server. To do this in Exchange Server 2003, use the Delivery Restrictions button on the Exchange General tab of the Mailbox properties. For more information about the Exchange General tab, visit the following Microsoft website:

http://technet.microsoft.com/en-us/library/aa997251.aspx

For more information about how to grant "send on behalf of" permissions in Exchange Server 2007, visit the following Microsoft website:

http://technet.microsoft.com/en-us/library/bb124406(EXCHG.80).aspx

For information about how to grant "send on behalf of" permissions in Exchange Server 2010, visit the following Microsoft website:

http://technet.microsoft.com/en-us/library/bb124255.aspx

For additional history on this problem, please see the original Hotfix articles where the IgnoreSOBError registry value was first introduced.

950794 Error message when you try to add a delegate in Outlook 2007: "The Delegates settings were not saved correctly"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;950794

946208 Error message when you try to add a delegate in Outlook 2003: "The Delegates settings were not saved correctly"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;946208

Back to the top | Give Feedback

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Back to the top | Give Feedback

Properties

Article ID: 2593557 - Last Review: October 15, 2012 - Revision: 7.0

 

Applies to

• Microsoft Outlook 2010

Keywords:

KB2593557

Back to the top | Give Feedback



 

A single MAPI session has exceeded the maximum number of objects of a given type.

Well we all have users with ENORMOUS mailboxes - even though there are no practical limits on mailbox size we all know that there are many more variables that influence the "actual" performance of email access (lan speeds, PC age, Exchange server sizing, etc)

We came across this at a few sites and the following helped us get around it.

Description:
This is caused by a very high usage level by an individual user. If these errors are happening regularly, you can raise the default maximum for the affected object type (for example, to twice its default level). If at this level the specified user is continuing to generate this warning, investigate the user actions that are causing this warning. It can be caused by improper client design or unusual client usage patterns.


Resolution for Exchange 2007

To resolve the problem, do the following:

•Investigate any third-party applications or add-ins that are running on the MAPI client. Some third-party applications keep objects open for long periods of time or open many objects concurrently.
(Blackberry server, Virus Scanners for Email Servers -- always run a separate gateway not on SERVER!!!)
•Investigate the user behavior that is associated with the indicated logon. This will help you better understand why the default number of objects is insufficient.

•In rare cases, you may need to add a registry key to adjust the maximum number of open objects. This new registry key will override the default value. Such rare cases include situations in which it is acceptable or necessary to use applications that keep objects open or open many objects concurrently.

Caution:
When you increase the maximum number of an object type, you also increase the memory that may be consumed by all client requests connecting to the server. Incorrectly configuring this value could lead to out-of-memory warnings or virtual memory fragmentation warnings.

Caution:
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Before You Begin
To perform the following procedure, the account you use must be delegated membership in the local Administrators group. For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.
Procedure

To use Registry Editor to adjust the maximum number of open objects that a MAPI client can use at the same time

1.Start Registry Editor (regedit).
2.Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
3.Right-click ParametersSystem, point to New, and then click Key.
4.Type MaxObjsPerMapiSession, and then press ENTER to name the new subkey.
5.Right-click MaxObjsPerMapiSession, click New, and then click DWORD Value.
6.Type the object type, and then press ENTER to name the entry. For example, type objtMessage, and then press ENTER to create an entry that changes the default maximum of objtMessage objects.
7.Right-click the entry that you created in Step 6, and then click Modify.
8.In the Value data box, type the new maximum number of objects to which you want to limit this entry, and then click OK.

Note:
The server will automatically recognize the new limit within five minutes.

Exchange Server Version??

When you look at the properties of an Exchange server you see the version number specifed as... 8.1.0240.006, etc..  To match the numeric build of Exchange to the actual version refer to the link below for the matching matrix.

Microsoft Exchange Server 2007 8.0.685.24 or 8.0.685.25
December 2006

Microsoft Exchange Server 2007 SP1 8.1.0240.006
November 2007

Microsoft Exchange Server 2007 SP2 8.2.0176.002
August 2009

Microsoft Exchange Server 2007 SP3 8.3.0083.006
June 2010

Microsoft Exchange Server 2010 14.00.0639.021
October 2009

Microsoft Exchange Server 2010 SP1 14.01.0218.015
August 2010



Build numbers and release dates for Exchange Server
Article ID: 158530
http://support.microsoft.com/kb/158530

Active Directory Schema Update Versioning

Ever wonder if a schema update applied properly or what version you are currently using?
Well these handy dsquery commands will make it easier:

For Active Directory Schema version

"dsquery * cn=schema,cn=configuration,dc=<< your domainname here>>,dc=local -scope base -attr objectVersion"

For Exchange Schema version

"dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=<>,dc=local -scope base -attr rangeUpper"

Reference the results for the above dsquery commandlets to the following lists below:


Schema version for operating system

13 - Windows 2000 Server
30 - Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
31 -Windows Server 2003 R2
44 - Windows Server 2008 RTM
47 - Windows Server 2008 R2

Schema version for Exchange application
4397 -Exchange Server 2000 RTM
4406 -Exchange Server 2000 With Service Pack 3
6870 -Exchange Server 2003 RTM
6936 - Exchange Server 2003 With Service Pack 3
10628 - Exchange Server 2007
11116 - Exchange 2007 With Service Pack 1
14726 - Exchange 2010 With Service Pack 1