none
Extended Protection has not been Enabled

    Question

  • I am running Exchange Server 2007 SP3 Update Rollup 2 on a Server 2008 R2 machine.  When I connect from my Windows 7 desktop to the EMC from the Management Tools of the same version, I get the following warnings:

    Get-OWAVirtualDirectory:  Exended protection has not been enabled. Install the operating system update specified in KB968389 on server "xxx.xxx.com" and try again. ........

    Get-OabVirtualDirectory:  Exended protection has not been enabled. Install the operating system update specified in KB968389 on server "xxx.xxx.com" and try again. ........

    Should I install the update?

    Thursday, December 16, 2010 6:25 PM

Answers

  • FYI

    This has finally been published:

    2538958 Extended Protection Warning Displayed in Exchange Management Console and Exchange Management Shell After Installing RU2 for Exchange 2007 SP3
    http://support.microsoft.com/default.aspx?scid=kb;en-US;2538958

    Should close the loop on this one :)  -  Thanks again everyone,
    Kevin Ca - MSFT

    -----

    Jon - Consider installing the hotfix, then troubleshoot separately the registry access issue. Alternatively you can run the firewall creation rules from the command prompt using the references in my posts above.


    Kevin Ca - MSFT
    Monday, May 02, 2011 3:38 PM

All replies

  • Hi Clarkson,

    "Should I install the update?"

    Please don't install the update. As KB968389 does not apply to 2008 R2.

    "When I connect from my Windows 7 desktop to the EMC from the Management Tools of the same version "

    What's the meaning of the "Management Tools of the same version"?

    Do you mean you also install the Exchange 2007 SP3 Update Rollup 2 on the Win 7 desktop?

    If yes, please remove the Rollup.

    Does the warning message occure on the Exchange 2007 server,either?

    Is it possible you install the management tool on another Win 7 to test?

    Frank Wang

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com  

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Proposed as answer by Dick Lai Friday, December 17, 2010 6:10 PM
    • Unproposed as answer by ClarksonAdmin Wednesday, May 04, 2011 3:52 PM
    Friday, December 17, 2010 7:41 AM
  • The management tools on my Windows 7 desktop are at the Exchange 2007 SP3 Update 2 level as well.  I applied update 2 because the tools had stopped working awhile back when we applied SP3.  Unfortunately, I can't remember the error, but it was a known issue.  There are NO problems with the EMC on the server itself--only when using them remotely. 

    Friday, December 17, 2010 6:11 PM
  • Hi Clarkson,

    Could you please remove the Rollup and Management Tool on the Win 7 client, then install the Management Tool again?

    If it is possible, please install the Management Tool on another Win 7 client to test.

     

    Frank Wang

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com  

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Monday, December 20, 2010 3:24 AM
  • I installed the tools on another Windows 7 64-bit client (the tools were from the Exchange 2007 SP3 setup files, no update rollups applied).  It seemed to work fine.  After installing Update rollup 2, I got this error:

    "Could not load file or assembly 'Microsoft.Web.Administration, Version=7.0.0.0, Culture=neutral, PublicKeyTokent=31bf3856ad364e35' or one of its dependencies.  The system cannot find the file specified."

    This was on a brand new Windows 7 installation.

    Monday, December 20, 2010 5:24 PM
  • We have the exact same problem, just on windows 2003.

    2 x frontend 2 x backend gives errors:

    [PS] C:\>Get-OwaVirtualDirectory -Server exfe01

    WARNING: Extended protection has not been enabled.  Install the operating system update

    specified in KB968389 onto server "exfe01.hosting.local" and try again.

    System.IO.IOException: The network path was not found.

     

       at Microsoft.Win32.RegistryKey.Win32ErrorStatic(Int32 errorCode, String str)

       at Microsoft.Win32.RegistryKey.OpenRemoteBaseKey(RegistryHive hKey, String

    machineName)

       at

    Microsoft.Exchange.Management.SystemConfigurationTasks.ExtendedProtection.LoadFromRegistr

    y(ExchangeVirtualDirectory exchangeVirtualDirectory, Task task)

     

    Name                          Server                        OwaVersion

    ----                          ------                        ----------

    owa (Default Web Site)        EXFE01                        Exchange2007

    The update is actually already installed...?


    Ole Jensen
    Tuesday, December 21, 2010 7:06 AM
  • I am receiving the same message.  However, I am not running my Exchange servers on 2008 R2. I am running on 2008 SP2.  I started receiving these warning immediatley after appling RU2 for SP3. I get the messages if I am using EMC from my workstation or from the server. 

    I have checked and KB968389 is installed on my servers.

    Tuesday, December 21, 2010 8:54 PM
  • I installed the tools on another Windows 7 64-bit client (the tools were from the Exchange 2007 SP3 setup files, no update rollups applied).  It seemed to work fine.  After installing Update rollup 2, I got this error:

    "Could not load file or assembly 'Microsoft.Web.Administration, Version=7.0.0.0, Culture=neutral, PublicKeyTokent=31bf3856ad364e35' or one of its dependencies.  The system cannot find the file specified."

    This was on a brand new Windows 7 installation.


    Hi Clarkson,

    Sorry for the delay.I test it in my lab, and same results as yours. If I remove the hotfix, it works again.

    From Technet:

    Where to Apply

    You should apply service packs or update rollup packages to each Exchange 2007-based server in an environment.

    How to Install the Latest Service Pack or Update Rollup for Exchange 2007
    So seems like you don't need to install the Rollup on the client as a workaround now(Though the download file addresses it is supported with Win 7).
    Frank Wang

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com  


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by ClarksonAdmin Wednesday, December 22, 2010 3:44 AM
    • Unmarked as answer by ClarksonAdmin Wednesday, January 05, 2011 7:57 PM
    • Edited by Frank.Wang Wednesday, May 18, 2011 7:24 AM
    Wednesday, December 22, 2010 3:14 AM
  • Thank you for your help.  I tried the client without any Update Rollups and it seems to work fine now.  I guess I was just under the assumption that clients needed to be at the same patch level as the servers. 
    Wednesday, December 22, 2010 3:44 AM
  • Any machine with Exchange 2007 components installed on it should eventually be at the same SP and RU level. That has long been a best practice.

    I don't understand why the moderator's suggestion of uninstalling the RU to make the error go away was marked as an answer, because it is not a solution to the problem of the new warning message.

    Taking client/admin only consoles out of the picture for a second as I think they confused the issue - I have multiple Exchange 2007 servers running SP3 and now RU2, and when I try to connect to a remote server using the EMC on a local server I get this error. I am certainly not going to uninstall the RU2 on my Exchange servers just to make the warning go away. I should be able to connect to a remote Exchange 2007 server using the EMC on a local Exchange 2007 server and not get this warning.

    My servers are all Windows 2008 SP2.

    So we need to find out what has changed in RU2 that is causing this error.

    Friday, December 24, 2010 7:16 AM
  • Hi,

    I agree with HotFix, the reply from Frank.Wang is not an answer. It just removes the error. Unfortunately, it also removes RU2.

    I have the same problem after having installed EX2007 SP3 RU2 on a Windows Server 2003 R2 x64 Edition with SP2.

    I installed the KB968389 update and configured the two registry keys: No joy..  After that, uninstalled RU2, rebooted the server, reinstalled RU2. Still the same problem.

    Regards,
    Ashley.

    Monday, December 27, 2010 1:17 PM
  • Are there any other suggestions for a possible answer?  Or a KB article to reference?
    Tuesday, December 28, 2010 3:55 PM
  • Agreed... It looks as though RU2 has some bugs...
    Tuesday, December 28, 2010 11:05 PM
  • Are we dead in the water since someone incorrectly marked the above moderator post as an answer to the quesiton? I.E. Is this thread being ignored by everyone now?
    Wednesday, January 05, 2011 7:29 PM
  • I'll unmark the answer for now.  Perhaps the moderator could further explain whether his answer is an acceptable solution or not.
    Wednesday, January 05, 2011 7:57 PM
  • FYI

    I have a Windows 2008 Server Environment that I just updated to Exchange 2007 SP3 RU2.  The management tools work fine on all my Exchange Servers without this error.

    However - I get the Extended Protection error with the 32-bit Managment Tools on a Windows 2003 Server I use to administer the environment (so I am not always logging on the mail servers).  I uninstalled the SP3 RU2 Update through Add/Remove programs and backed it out to SP3 RU1 and no longer get the error.  Sounds like there is a bug in SP3 RU2 that needs to be fixed.

     

    Saturday, January 08, 2011 5:39 PM
  • Hi Everyone,

    I've been doing some digging on this (specifically what is included in RU2) and i see a particular internal update that was added, which may have something to do with what's causing this.

    I can setup a repro internally, and go through the channels necessary to see if we can figure out what's going on, but unfortunately this will take me some time, perhaps a week or 2.

    1 interesting thing i noticed in searching our internal database is that we don't have any existing cases/tickets open regarding this issue, but clearly it is affecting several installs. Has anyone considered opening a support case to report this issue with RU2? There is no charge if it is indeed caused by RU2, and in most cases it helps to speed up the process with getting an answer.

    Otherwise, i will work on this over the next week or 2 and get back to everyone ASAP.

    Thanks,
    Kevin Ca - MSFT
    Exchange Support Team


    Kevin Ca - MSFT
    Thursday, January 13, 2011 12:21 AM
  • Hello All,

    I did work on a similar issue this was found to be the solution in that case:

    Cause -

    IIS manager service was not installed on the machine.

    Resolution -

    Server manager | Roles --> Web server --> Management Tools --> IIS management Console It was not installed.

    Let me know, if this helps.

    Regards,

    Mukesh

    Friday, January 14, 2011 5:39 AM
  • @Kevin Ca - MSFT - if my team wasn't so overloaded at the moment we would jump on this, but as it is we are hoping someone else experiencing this issue has the spare time to resolve it.

    @Mukesh - I also experienced an error on one of my servers that didn't have the IIS Manager installed, and installing it removed the error. This however is a different scenario than what I experienced with the error in that this is a warning, and I get it any time I connect to a remote Exchange server, even while on a full Exchange server, even with IIS Manager being installed on the source and target.

    Hopefully someone can open a case on this and get to the bottom of it.

    Friday, January 14, 2011 7:44 PM
  • Have any of you actually read the KB article in question?  Simply installing the update does not enable the functionality and it seems that is what Exchange is complaining about...

    From http://support.microsoft.com/kb/968389:

     

    After you install this security update, you must implement the following registry subkey settings to enable Extended Protection:

     

    ·     Set the registry subkey value for HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection to "0" (zero) to enable protection technology. By default, this registry subkey is not created when the security update is installed. If this registry subkey is not created, Extended Protection is disabled. When you set the SuppressExtendedProtection registry entry to "1" or when you delete this subkey, Extended Protection is disabled. When you set the SuppressExtendedProtection registry entry to "3" Extended Protection is disabled and channel bindings sent by Kerberos are also disabled, even if the application supplies them.

    ·     Set the registry subkey value for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel to "3." This is not the default on Windows XP and Windows Server 2003. This is an existing key which enables NTLMv2 Authentication. Extended protection for Windows authentication only applies to NTLMv2, Kerberos, digest, and negotiation authentication protocols and does not apply to NTLMv1.

    Note You must restart your computer after you set the SuppressExtendedProtection and the LmCompatibilityLevel registry values on a Windows XP-based computer.

    Note: You should definitely read the entire article and decide whether this is something you actually want/need to turn on in your environment.  Since it is disabled by default, it most likely can cause big problems in some situations!

    Ryan

    Monday, January 17, 2011 2:38 PM
  • Hello,


    This issue looks to be somewhat "known", and currently under investigation.

    In the meantime, i was able to workaround the issue with a partially modified set of steps from the following blog:
    http://mvolo.com/blogs/serverside/archive/2008/05/26/Accessing-IIS-7.0-configuration-remotely-and-on-server-core.aspx

    To test whether or not the steps i have listed below will work for you, you could disable all firewalls on and between the client and server in question (if possible :) )

    The exact steps i took were:

    1. Disable firewall or create firewall rules to allow a fixed port and RPC:
    -- Open CMD and run:  "REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{9fa5c497-f46d-447f-8011-05d03d7d7ddc} /v EndPoints /d "ncacn_ip_tcp,0,7000" /t REG_MULTI_SZ /f"

    2. Used NETSH to add the following rules:

    -Type "NETSH" then enter
    -Type "ADV FIR" then enter
    - Run: add rule name="RPC Mapper" dir=in action=allow remoteip=any protocol=tcp localport=135 service=rpcss
    - Run: add rule name="AHADMIN Fixed Endpoint" dir=in action=allow remoteip=any protocol=tcp localport=7000 program=%windir%\system32\dllhost.exe
    - Run: add rule name="AHADMIN Fixed Endpoint" dir=in action=allow remoteip=any protocol=tcp localport=rpc program=%windir%\system32\dllhost.exe

    3. To review these type:
    show rule name="AHADMIN Fixed Endpoint"
    show rule name="RPC Mapper"

    4. Close EMC on the client and reopen... (You can also test with get-owavirtualdirectory in the management shell)

    ====================================

    PLEASE NOTE: These steps should be tested in a lab and thoroughly reviewed before implementing. The blog explains what we are doing with these rules and why. In my example, i chose port 7000 only after verifying no other programs were using it.

    Again, at this point this would appear to be a workaround as it looks like this is being investigated. I would hope to be able to provide more details at a later time. In short, i believe the KB article it reports isn't the actual issue but an effect.

    Thanks,
    Kevin Ca - MSFT

     


    Kevin Ca - MSFT
    Monday, January 24, 2011 1:49 AM
  • In my case I have disabled the firewall on both the client and the server and still generated the error. The pre-requisites for installing EMC on a Windows 7 client are not probably updated.
    Tuesday, January 25, 2011 6:53 PM
  • Hello All,

    Just wanted to provide a comment that this post/issue has not been forgotten.
    I'm working internally with several people to research this and hopefully provide a fix.

    I will keep you updated, and forecase another update within 1 to 2 weeks.

    Thanks,
    Kevin Ca - MSFT


    Kevin Ca - MSFT
    Monday, January 31, 2011 1:11 AM
  • Hi Everyone,

    I've been doing some digging on this (specifically what is included in RU2) and i see a particular internal update that was added, which may have something to do with what's causing this.

    I can setup a repro internally, and go through the channels necessary to see if we can figure out what's going on, but unfortunately this will take me some time, perhaps a week or 2.

    1 interesting thing i noticed in searching our internal database is that we don't have any existing cases/tickets open regarding this issue, but clearly it is affecting several installs. Has anyone considered opening a support case to report this issue with RU2? There is no charge if it is indeed caused by RU2, and in most cases it helps to speed up the process with getting an answer.

    Otherwise, i will work on this over the next week or 2 and get back to everyone ASAP.

    Thanks,
    Kevin Ca - MSFT
    Exchange Support Team


    Kevin Ca - MSFT

    Hi - I'm experiencing exactly this problem, on a new fresh install of 2007 SP3 RU2 - turning the firewall off (Windows Server 2008 SP2) solves the problem.

    Therefore I've logged a support call as requested, hopefully that'll help with an official answer.

    Regards

    --Tosh

    Thursday, February 10, 2011 10:06 AM
  • Have any of you actually read the KB article in question?  Simply installing the update does not enable the functionality and it seems that is what Exchange is complaining about...

    From http://support.microsoft.com/kb/968389 :

     

    After you install this security update, you must implement the following registry subkey settings to enable Extended Protection:

     

    ·      Set the registry subkey value for HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection to "0" (zero) to enable protection technology. By default, this registry subkey is not created when the security update is installed. If this registry subkey is not created, Extended Protection is disabled. When you set the SuppressExtendedProtection registry entry to "1" or when you delete this subkey, Extended Protection is disabled. When you set the SuppressExtendedProtection registry entry to "3" Extended Protection is disabled and channel bindings sent by Kerberos are also disabled, even if the application supplies them.

    ·      Set the registry subkey value for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel to "3." This is not the default on Windows XP and Windows Server 2003. This is an existing key which enables NTLMv2 Authentication. Extended protection for Windows authentication only applies to NTLMv2, Kerberos, digest, and negotiation authentication protocols and does not apply to NTLMv1.

    Note You must restart your computer after you set the SuppressExtendedProtection and the LmCompatibilityLevel registry values on a Windows XP-based computer.

    Note: You should definitely read the entire article and decide whether this is something you actually want/need to turn on in your environment.  Since it is disabled by default, it most likely can cause big problems in some situations!

    Ryan


    On my default Windows 2008 SP2 installation with the hotfix applied, SuppressExtendedProtection doesn't exist and LmCompatibilityLevel is set to 0.

    Changing/setting these values doesn't change the issue, it still exists.

     

    T

    Thursday, February 10, 2011 10:10 AM
  • I have tested Kevin's workaround in a lab, and it seems that these steps indeed mitigate the issue, but a real fix will be needed in the next update rollup.  When using the Exchange 2007 SP3 UR2 console, the warning no longer appears after editing the firewall rules and registry keys.  However, it seems that with Get-OwaVirtualDirectory there is still some red and yellow:

    WARNING: An unexpected error has occurred and debug information is being

    generated: Creating an instance of the COM component with CLSID

    {2B72133B-3F5B-4602-8952-803546CE3344} from the IClassFactory failed due to the

     following error: 80070005.

    Get-OwaVirtualDirectory : Creating an instance of the COM component with CLSID

    {2B72133B-3F5B-4602-8952-803546CE3344} from the IClassFactory failed due to the

     following error: 80070005.

    At line:1 char:24

    + Get-OwaVirtualDirectory <<<<

        + CategoryInfo          : NotSpecified: (:) [Get-OwaVirtualDirectory], Una

       uthorizedAccessException

        + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.Exc

       hange.Management.SystemConfigurationTasks.GetOwaVirtualDirectory

    Thursday, February 10, 2011 9:38 PM
  • Hi Tosh,

    Thanks for noting that in this post. I will see if i can find your case number and take ownership of it to consolidate it with the rest that we have. The more the merrier. :) 

    To provide an update to everyone else; we are actively working on this and consolidating open cases, however, it is hard to give an estimated time at this point given that fixes are worked on by priority and demand. I will keep this thread updated periodically.

    Regards,
    Kevin Ca - MSFT


    Kevin Ca - MSFT
    Friday, February 11, 2011 3:05 AM
  • Hello,

    I have a similiar issue as Mancer Blackshear with "Get-ActiveSyncVirtualDirectory" but another error. It seems like the issue came after upgrading the Exchange 2007 environment to SP3/RU1.

    My setup
    2 node SCC Exchange 2007 cluster on Windows 2003 servers
    1 CAS/HUB Exchange 2007 server on Windows 2003 server
    2 CAS/HUB Exchange 2010/SP1 on Win2008R2
    2 MBX (to form a DAG) on Win2008R2 (DAG not created yet)
    All servers have disabled firewalls.

    My problem
    All command work fine locally on the Exchange 2007 server (Get-ActiveSyncVirtualDirectory & Get-OwaVirtualDirectory Get-OabVirtualDirectory). On the Exchange 2010 server 2 commands work fine (Get-OwaVirtualDirectory Get-OabVirtualDirectory) but not Get-ActiveSyncVirtualDirectory. 

    Get-ActiveSyncVirtualDirectory errors out with the following (on all Exchange 2010 servers):

     

    WARNING: An unexpected error has occurred and a Watson dump is being generated: Retrieving the COM class factory for remote component with CLSID {2B72133B-3F5B-4602-8952-803546CE3344} from machine host.domain.com failed due to the following error: 80040154.

    Retrieving the COM class factory for remote component with CLSID {2B72133B-3F5B-4602-8952-803546CE3344} from machine host.domain.com failed due to the following error: 80040154.

        + CategoryInfo          : NotSpecified: (:) [Get-ActiveSyncVirtualDirectory], COMException

        + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.Exchange.Management.SystemConfigurationTasks.GetMobileSyncVirtualDirectory

     

     

    Any ideas of how to solve this error ? 

     

    I was told by James Chong to update this thread. I orginally posted in the following thread:
    http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/8afaf497-d0b7-40bd-a58b-b228e34007da/?prof=required

     

    Regards,

    Rikard Strand

    Sunday, February 20, 2011 11:05 AM
  • Hello,

    The fix/solution for this is making slow and steady progress, but there is progress since my last post.

    Please stay tuned as i will try to keep everyone on here updated as much as possible. Also, if you have opened a case for this issue please feel free to update this thread for consolidation. Do NOT put any personal information on here (like name, SR #, etc), i can find the case by the date created and the product itself.

    Thanks!
    Kevin Ca - MSFT


    Kevin Ca - MSFT
    Tuesday, February 22, 2011 8:18 PM
  • Hi,

    I am having exactly same error. Hoping to have this fix before I migrate all my users to these servers.

    Thanks,

    Shri

    Thursday, February 24, 2011 6:30 AM
  • @Shrijapan

    This thread was originally opened regarding the warning message of "Extended Protection has not been Enabled". If that is the "error" you are seeing, you should be fine to migrate your users to these servers as it is a warning and nothing more.

    If you are referring to another error, as some others have added to this forum, then I think you will have to wait and see what the recommendation is from Microsoft.

    @All

    It seems as if this thread has mutated from issues about the originally reported warning message, to other people adding in additional errors they are seeing. I am hopeful the reports from MSFT that they are workign on a fix is for the warning message because I suspect the error messages are being caused by something else.

    Thursday, February 24, 2011 7:09 PM
  • To provide an update to everyone else; we are actively working on this and consolidating open cases, however, it is hard to give an estimated time at this point given that fixes are worked on by priority and demand. I will keep this thread updated periodically.

    Hi Kevin/All

    As you know - 2007 SP3 Rollup 3 was released - I've applied this to my 6 Exchange 2007 servers, turned the Windows Firewall on, and still have the same problem.

    I'm implementing the workaround Kevin supplied in the posts above, as we're going into testing tomorrow - the workaround resolves the warning/error in EMC and EMS.

    T

    Wednesday, March 09, 2011 2:26 PM
  • Hello MrBeach,

    We have the exact problem, also migrating from 2007 to 2010, everthing else works fine, like get-owavirtaldirectory etc.. but the only thing that doesn't work is get-activesyncvirtualdirectory, on the 2007 machine it runs OK but on the new 2010 server not, so if you want to configure the external client acces domain in the EMC, we get the same error, we are stuck at the moment, please help

    Do you have a fix already?

     

    Thanks

    Bart

    Tuesday, March 15, 2011 9:16 AM
  • Hello Bart,

    In my case I got the error when running the get-activesyncvirtualdirectory (this command also runs as part of configuring certificates using EMC). My solution was to identify certificate needs by hand and doing the certfificate requests manually using powershell. So basically I did manually steps to "go around" the problem.

    So in my case I have successfully migrated to Exchange 2010. After the migration I had some problems with a password prompt in Outlook which was related to wrong configuration of the Internal/External URL's of the Exchange 2007 environment (that autodiscover downloads when starting Outlook).

     

    Regards,

    Rikard Strand

    Tuesday, March 15, 2011 10:37 AM
  • Hello everybody, just to say that we are experiencing the same problem related to message:

    [PS] C:\Documents and Settings\Administrator.mydomain>Get-OwaVirtualDirectory
    WARNING: Extended protection has not been enabled.  Install the operating
    system update specified in KB968389 onto server "mailserver.mydomain.com.mx"
    and try again. System.IO.IOException: The network path was not found.

       at Microsoft.Win32.RegistryKey.Win32ErrorStatic(Int32 errorCode, String
    str)
       at Microsoft.Win32.RegistryKey.OpenRemoteBaseKey(RegistryHive hKey, String
    machineName)
       at
    Microsoft.Exchange.Management.SystemConfigurationTasks.ExtendedProtection.LoadF
    romRegistry(ExchangeVirtualDirectory exchangeVirtualDirectory, Task task)

    Name                       Server                     OwaVersion
    ----                       ------                     ----------
    owa (Default Web Site)     MAILSERVER              Exchange2007

    now, the hotfix has already been applied, I also made the change at the registry level as the KB states; I've already installed Exchange 2007 SP3 RU3 and the problem continues.

    I've also noticed that I cannot create new "Receive Connectors", I tried to create a new receive connector named "Relay" and this is the message I get:

    Summary: 1 item(s). 0 succeeded, 1 failed.
    Elapsed time: 00:00:00


    Relay
    Failed

    Error:
    Active Directory operation failed on domaincontroller.mydomain.com.mx. This error is not retriable. Additional information: The parameter is incorrect.
    Active directory response: 00000057: LdapErr: DSID-0C090B38, comment: Error in attribute conversion operation, data 0, vece

    The requested attribute does not exist.

    Exchange Management Shell command attempted:
    new-ReceiveConnector -Name 'Relay' -Usage 'Custom' -Bindings '172.16.1.20:25' -Fqdn 'mailserver.mydomain.com.mx' -RemoteIPRanges '172.16.1.3-172.16.1.3' -Server 'MAILSERVER'

    Elapsed Time: 00:00:00

    Our Environment:

    Exchange Server 2007 SP3 RU3

    Windows Server 2003 x64 SP2

    Hope this provide more info in order to resolve the issue.


    Enrique Carbonell
    Friday, March 18, 2011 1:28 AM
  • Hello Everyone,


    We are still working out the documentation and proposed fix for this issue. The explanation I’ve gotten for this is as follows:

     

    This is caused by a channel binding implementation that was fixed in Rollup Update 2. We need to create a COM object (Microsoft.Web.Services) on the remote server to access the IIS Metabase of the remote server. We set the channel binding options on the Metabase causing the IIS server to implement channel binding. The problem is when a firewall is turned on, ahadmin can’t create the COM object through the firewall. The generic message displayed assumes you want to implement channel binding but isn’t specific enough to tell you the problem is the firewall.”

     

    Right now the fix is to implement the firewall rules that I listed above.

     

    There appear to be several variations posted in this thread. In short, if creating the firewall rules as mentioned above does not resolve your issue, you are experiencing a different problem and should troubleshoot it accordingly.

    We are working to get a public document explaining this issue in detail with an official solution/fix. My goal is to have this within a couple of weeks, but again, for now, the firewall rules should be used to work around the warning displayed.

     

    Thanks to everyone for your patience.
    Kevin Ca - MSFT


    Kevin Ca - MSFT
    Wednesday, March 23, 2011 5:48 PM
  • Don;t know where we stand on this...  no update for a month now.  My experience with this error is accessing an Exchange 2007 server on a WS2008 ENT SP2 fully patched VM frrom a XPSP3 workstation also fully patched.  The problem I have, is that neither the workstation or the exchange server has the Windows firewall enabled.  They are both inside the corp firewall.  So...  is this a unique issue to what I'm reading above (dount it...  not much on this error out there)  and is this simply a nusiance error or is there actually something going on I should be concerned about??
    Chris
    Monday, April 25, 2011 6:34 PM
  • Hello Everyone,

    Here is the latest.

    I have written a knowledge base article that should be published soon. It explains the root cause, as well as the workaround. We have also developed a hotfix that you can request by calling support and referencing the knowledge base article number:  2538958

    If you have any issues with obtaining the hotfix, please ask the engineer to contact the article author for details.

    I'll provide another update once the KB article has been published. However, the root cause and workaround remain the same as in my previous posts.

    Thanks for the patience everyone,
    Kevin Ca - MSFT


    Kevin Ca - MSFT
    • Marked as answer by ClarksonAdmin Thursday, April 28, 2011 3:12 PM
    • Unmarked as answer by ClarksonAdmin Wednesday, May 04, 2011 3:52 PM
    Thursday, April 28, 2011 2:05 AM
  • Hey Kevin,

    What do you do when the machine you are trying to fix is Windows 2008 R2 and registry access is denied?

    Friday, April 29, 2011 5:44 PM
  • FYI

    This has finally been published:

    2538958 Extended Protection Warning Displayed in Exchange Management Console and Exchange Management Shell After Installing RU2 for Exchange 2007 SP3
    http://support.microsoft.com/default.aspx?scid=kb;en-US;2538958

    Should close the loop on this one :)  -  Thanks again everyone,
    Kevin Ca - MSFT

    -----

    Jon - Consider installing the hotfix, then troubleshoot separately the registry access issue. Alternatively you can run the firewall creation rules from the command prompt using the references in my posts above.


    Kevin Ca - MSFT
    Monday, May 02, 2011 3:38 PM
  • Thanks for the follow up Kevin, it is really good to close the loop on this one.

    • Proposed as answer by WBMSoft Thursday, June 16, 2011 1:36 AM
    • Unproposed as answer by WBMSoft Thursday, June 16, 2011 1:41 AM
    • Proposed as answer by WBMSoft Thursday, June 16, 2011 1:41 AM
    • Unproposed as answer by ClarksonAdmin Thursday, June 16, 2011 12:41 PM
    Wednesday, May 04, 2011 3:50 PM
  • 1. Create firewall rules to allow a fixed port COM calls:

    Directly from a Microsfot Support Incident I just finished. If the Windows Firewall is OFF on both servers this is not a problem. If the firewall is to be on then follow steps below: This is a bug and the support incident was not charged.

    Open CMD and run:

    REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{9fa5c497-f46d-447f-8011-05d03d7d7ddc} /v EndPoints /d "ncacn_ip_tcp,0,7000" /t REG_MULTI_SZ /f

    2. Use NETSH to add the following rules:

    -Type NETSH then enter
    -Type  ADV FIR then enter
    - Run: add rule name="RPC Mapper" dir=in action=allow remoteip=any protocol=tcp localport=135 service=rpcss
    - Run: add rule name="AHADMIN Fixed Endpoint" dir=in action=allow remoteip=any protocol=tcp localport=7000 program=%windir%\system32\dllhost.exe
    - Run: add rule name="AHADMIN Fixed Endpoint" dir=in action=allow remoteip=any protocol=tcp localport=rpc program=%windir%\system32\dllhost.exe

    To review these type:
    show rule name="AHADMIN Fixed Endpoint"
    show rule name="RPC Mapper"

    Close EMC on the client and reopen... (You can also test with get-owavirtualdirectory in the management shell)


    "The power of accurate observation is commonly called cynicism by those who have not got it." George Bernard Shaw
    Thursday, June 16, 2011 1:43 AM
  • Kevin,

    Will this fix be included in a future Rollup?  I installed RU4 for Exchange 2007 sp3 this weekend and had hoped this would be in there but it apparently was not.

    Thanks,

    Tom

    Monday, July 25, 2011 5:23 PM
  • Tom,

    The fix was not included in RU4. When you apply RU4, you will first need to remove the existing IU, update to RU4, then obtain an updated Interim Update from Microsoft for RU4.

     


    Kevin Ca - MSFT
    Monday, July 25, 2011 8:56 PM
  • OK, so to actually answer your question :) (read it the first time too fast)  - I believe we are trying to include it with the next RU, but there is no way i'd be able to confirm that right now.
    Kevin Ca - MSFT
    Monday, July 25, 2011 8:59 PM
  • Thanks Kevin - will you update the thread if you do hear it is in RU5?

    -Tom

    Tuesday, July 26, 2011 6:31 PM
  • I had this issue after applying UR11 for E2007 SP3 on my Win7 client.  IIS 6 MC was installed, but the IIS Management Service and Console were not - I added them and the problem went away.  Thanks for this!
    Wednesday, October 02, 2013 4:26 PM