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

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



 

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

The source server is currently rejecting replication requests

I got this error while troubleshooting an environment with two DC’s that were not replicating. This error popped up when I tried to manually replicate in AD sites and services.

I used the repadmin tool to troubleshoot and found that the server had replication turned off.

Repadmin /option *servername* -- this will show you what the current settings are for the DC in question.

Enabling replication resolved the issue, here is the syntax

Use both:

repadmin /options *servername* -disable_inbound_repl

repadmin /options *servername* -disable_outbound_repl

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.