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

Exchange 2007: How to allow relay exceptions

Although allowing unfettered relaying of e-mail through your Exchange 2007 server should be avoided, there are situations in which allowing relaying is desirable.

For example, suppose you have an HVAC system that reports to operations when a building’s air handling system strays outside preset parameters. These systems typically handle their reporting via e-mail and don’t authenticate with your SMTP server. The system simply needs your SMTP server in order to correctly route the message. In Exchange 2007, relay is made available through the use of a custom SMTP receive connector. I should note that, by default, Exchange 2007 does support relaying of mail for systems that authenticate. Today’s tip focuses on relaying from an unauthenticated system.

Before you get started, you should add another IP address to the network adapter on your Exchange server. An SMTP receive connector is akin to a SMTP virtual server from Exchange 2003 and requires a unique IP address/SMTP port combination. It’s easier to tell a third-party system to use a different IP address for relay than it is to provide it with a different port to use for SMTP. I’ve assigned the IP address 192.168.1.10 to my system.

Step by step guide to allowing relay
To allow individual systems to relay mail through your Exchange 2007 system, perform the following steps:
1. Start the Exchange Management Console.
2. Browse to Microsoft Exchange > Server Configuration > Hub Transport.
3. Select the Hub Transport server through which you would like to allow another system to relay mail.
4. From the Actions pane, choose New Receive Connector (Figure A).
5. On the first page of the New SMTP Receive Connector wizard, type a name for the connector and choose the connector’s intended use. In this case, choose Custom
Type a name and choose a use for this connector.
6. Choose Next.
7. On the Local Network Settings page, click the Add button
8. On the Local Network settings page, click the Add button and, in the Add Receive Connector Binding window, type in the new IP address that you gave to the network adapter. Leave the SMTP port at 25.
9. Choose OK.
10. Under Local IP address(es), select All Available and click the red X to delete this selection.
Decide which IP address and port combination to use for the new connector.
11. Choose Next.
12. On the Remote Network Settings window, indicate which systems or range of IP addresses should be allowed to relay through this connector. In the example shown the host system with IP address 192.168.1.200 and any system with an IP address in the range 192.168.1.0 to 192.168.1.254 will be allowed to relay through this connector.
Indicate the systems with rights to relay through this connector.
13. Choose Next.
14. On the summary screen, click the New button to create the connector.
15. Open the properties page of the new connector. To do so, right click the new connector and choose Properties.
16. From the connector’s Properties page, choose the Permission Groups tab (Figure E).
17. Select the checkbox next to “Exchange Servers”.
Select Exchange Servers. You must do this before you continue.
18. From the connector’s Properties page, choose the Authentication tab.
19. Select the checkbox next to “Externally Secured (for example, with IPsec)”.
Select External Secured to tell Exchange that the third party device somehow manages it own permissions.
20. Choose OK.

At this point, you should be able to relay from the third party system.

Blackberry Server Compatibility Matrix -- Exchange Service Packs !!

Remember always check the matrix BEFORE applying any of the Exchange Service Packs or else you may find yourself doing some emergency Blackberry Server upgrades at the same time!

See link for latest matrix:
http://na.blackberry.com/eng/support/software/server_compatibility.jsp#tab_tab_compatibility

Uninstall Exchange 2007 SP1 Mailbox role from Server 2008 R2

If you are getting error:
"An error occurred. The error code was 3221685466. The message was The service is already registered.." while trying to uninstall Exchange 2007 SP1 Mailbox role from Server 2008 R2

Try changing registry key value from "Uninstall" to "Install" located at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\Mailbox\
after that try uninstalling again.

Your mileage may vary -- so far it's worked 5 out of 6 tries for us.

Exchange 2007 - Problem loading a certificate to be used for STARTTLS Purpose

Great reference point on resolving this "annoying" error message.


Alert : Exchange 2007 - Problem loading a certificate to be used for STARTTLS Purpose.

Generally this condition occurs if one or both of the following conditions is true:

1. The fully qualified domain name (FQDN) that is specified in the Warning event has been defined on a Receive connector or Send connector on a Microsoft Exchange Server 2007 transport server, and no certificate is installed on the same computer that contains the FQDN in the Subject or Subject Alternative Name fields.

2. A third-party or custom certificate has been installed on the server and it contains a matching FQDN. However, the certificate is not enabled for the SMTP service Others Exchange


Knowledge Base Details
Possible Cause :

As per Microsoft: "This Warning event indicates that there is a problem loading a certificate to be used for STARTTLS purposes. Generally, this problem occurs if one or both of the following conditions is true:
- The fully qualified domain name (FQDN) that is specified in the Warning event has been defined on a Receive connector or Send connector on a Microsoft Exchange Server 2007 transport server, and no certificate is installed on the same computer that contains the FQDN in the Subject or Subject Alternative Name fields.
- A third-party or custom certificate has been installed on the server and it contains a matching FQDN. However, the certificate is not enabled for the SMTP service".


User Acton :

1. Open "Exchange Management Shell".

2. Write "get-ExchangeCertificate" and press on "Enter" button.

3. Write down the Thumbprint of the certificate that reflect the required FQDN name of the server.

4. Review the current certificate that use by the Exchange server and

each certificate function.

5. Write "Enable-ExchangeCertificate -Thumbprint 2afd26617915932ad096c48eb3b847fc7457662 -Services "SMTP"

and press on 'Enter" button.

The value of -Thumbprint obtained in stage 3.

6. Restart the Exchange server.


For Creating a Certificate or Certificate Request for TLS check the below article

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