Good day,

Are there known bugs related to the Ducht language and calendar settings ?

When creating a new mailbox the calender is called "Kalender" in Dutch. This should be "Agenda"

Now when running a new pst import a folder "Kalender" already exists and "Agenda" is created as an extra calendar.
I am in the proces of migrating several mailboxes to Exchange 2013 using pst imports of the old mailboxes. After every import the user has 2 calendars with different names !

Any solutions ?

Please see the screenshots:

Hi,

I use Outlook 2013 connected to office 365 Exchange and it has been working for months, on the 30th of May it started pooping up with the error shown above (Windows 7 x64), eventually I removed the email account but now when I try to add it again I continually get the same error.

I currently have to use mobile Android device (no issue), Mac with outlook, windows 8 tablet or OWA to access my emails. OWA works from the windows 7 laptop in question without issue.

It is only affecting my windows 7 x64 laptop?

I have repaired Microsoft Office Pro 2013 from control panel and the problem is still there.

There are four other users on the office 365 account who have no problems.

Thanks

Luke

Company just upgraded from Office 2010 to 2013.  Every time I go to manage my rules and alerts, I get the message:
"The rules on this computer do not match the rules on Microsoft Exchange.  Only one set of rules can be kept.  You will usually want to keep the rules on the server.  Which rules do you want to keep?"

The first time I saw this message yesterday after the upgrade, I selected "Server".  I then went to view the rules, and they were all in alphabetical order.  This would completely ruin the way I use rules and the way I have them organized.  I cancelled out of that window and went in again clicking on the "Client" button.  This brought up all the rules I had previously, and in the correct order.  Once I made a change, I got the progress bar showing that it was uploading the rules to the server.  However, every time I go back to Manage Rules, I get the same client/server challenge prompt.  FWIW, these are all client-side rules, that move messages from my Exchange Inbox to specific folders in my PST.

I also noticed that when I view the rules from the server, my inactive rules are missing.  I have some rules that are unchecked, but will activate them at certain times of the year.

I've done some searches on this topic, and all I can find is the Knowledge Base article that talks about having two versions of Outlook accessing the same Exchange account.  This is not my issue.  I only have the one version of Outlook accessing my account on the Exchange server.

Is there any way to bypass the "Rules Do Not Match" prompt, and force Outlook to always use my client-side rules?

Hi,

I have foolwing issue: I have a coexistence szenario (EX2010 Sp3 and Ex2013 CU1) and I have an issue with OWA on EX2013 server:

When accessing url https://myex2013server/owa (on ex2013) on new server everything is fine (with user on EX2010 and EX2013).

When accessing url https://myex2013server (on ex2013) I get the OWA-FBA site (is this behaviour correct?). When I log in with a user who is on EX2010 the site is not displayed correctly (see picure). When I log in with a user who is on EX2013 the site is displayed correctly.

Any ideas?

Thanks in advance

as Exchange 2013 is now supported with UAG SP3,  is this better to use UAG rather than using TMG for new deployments..if yes.. is there any configuration available on technet for Publishing Exchange 2013 using UAG....any experience share will be highly appreciated...

Thanks..

Dear all,

Previously in Exchange Server 2010, we could configure allowed or blocked file types for an OWA Virtual Directory in EMC with a nice pull down menus. However, i found that this feature was removed in Exchange Server 2013's EAC.

When i tried to use "Get-OwaVirtualDirectory" command as follow (with the FT option even), I am unable to access the full list of default allowed and blocked file types.

I have also tried to use LDP.exe or ADSIEDitor to retrieve to relevant AD attributes, still can get the full list from the "msExchOWABlockedFileTypes".

Moreover if i could not have the list on hand and run this command:-

Set-OwaVirtualDirectory "owa (Default Web Site)" -BlockedFileTypes '.txt'  

I am actually unblocking all other file types since the above command replaces the default blocked list of filetypes... am i correct?

Is there anyone have a solution which could let us customize the allowed/blockedfiletypes list?

Hoping for your reply, thanks a lot.

Larry Chan

I run this command to stop users from changing their photos.

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -SetPhotoEnabled $false

Now, i need to allow members from HR to change photos on behalf of the users.

IN ecp, there are a few admin roles :

help desk, recipient management, organization management.

which role will allow them to perform their jobs?

As an administrator myself, i can login in as another user to do that. but i dont want to give HR admin roles

Any tips?

Hello,

we have moved 1 client to Exchange 2013, after that we have encountered slow access from Windows XP Client

Version 8 - 9

Even though these is supported?

Anyone else have encountered this?

Lars

My exchange email sends and receives emails to literally any other domain, but when attempting to send an email to one specific domain set (for example, bob @ bob . com, burger @ bob . com, and place @ bob . com) it immediately bounces back and gives me this:

Received: from BY2PR04MB224.namprd04.prod.outlook.com (10.242.41.12) by
 BY2PR04MB223.namprd04.prod.outlook.com (10.242.41.28) with Microsoft SMTP
 Server (TLS) id 15.0.698.13; Tue, 4 Jun 2013 16:24:18 +0000
Received: from BY2PR04MB224.namprd04.prod.outlook.com ([169.254.4.157]) by
 BY2PR04MB224.namprd04.prod.outlook.com ([169.254.4.157]) with mapi id
 15.00.0698.010; Tue, 4 Jun 2013 16:24:18 +0000
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: (removed)
Subject: Test
Thread-Topic: Test
Thread-Index: AQHOYT/1qdXwKmimNkeepdovbOHKWg==
Date: Tue, 4 Jun 2013 16:24:17 +0000
Message-ID: <00d7c0f070b34f278b30bfd858c74df2@BY2PR04MB224.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator: <00d7c0f070b34f278b30bfd858c74df2@BY2PR04MB224.namprd04.prod.outlook.com>
MIME-Version: 1.0
X-Originating-IP: [50.155.134.231]
Return-Path: (removed)
X-Forefront-Antispam-Report:
 SFV:SKI;SFS:;DIR:OUT;SFP:;SCL:-1;SRVR:BY2PR04MB223;H:BY2PR04MB224.namprd04.prod.outlook.com;LANG:;
I've spent nearly two weeks attempting to solve this, and have gotten nowhere. To be clear, I encounter this issue when sending from both my desktop outlook, and the outlook web portal on the Office 365 website. The email accounts that I cannot send to are hosted with godaddy, who I have contacted multiple times about it, and have been told from that the email from my exchange account does not appear to ever leave the exchange server. I have to admit that this issue has been infuriating; All I need to do is send a simple email and I cannot do so. This entire issue stems from the fact that Microsoft, for some reason, does not offer the laughably basic functionality to sync Windows Phone 8 directly with your desktop Outlook (something that both iOS and Android do out of the box, incidentally) so I was forced to setup an Exchange account with an alias in order to be able to sync my mail and calendars with my outlook (as well as reply to emails and make new calendar appointments from my phone and sync it with my desktop Outlook).

Note, I first logged this in the Office forums.  It was suggested I re-enter here.

Outlook 2013 notification photos are mismatched!

Hello,

I have Exchange 2013 environment on Win2k12.

Exchange 2013 CU1 - Mailbox server

Exchange 2013 CU1 - CAS server

before upgrading to CU1, I configured the OwaVirtualDirectory and EcpVirtualDirectory with BasicAuthentication to False and my clients had SSO to OWA.

But after the upgrade to CU1, my clients do not have SSO and cannot even logon until I change the BasicAuthentication to True.

What have been changed in CU1 that causing this issue?

Regards.

I am working on deploying a new 2013 Exchange server. The Exchange is installed on a 2012 Server OS. I have three windows terminal servers (or remote desktop services) at three separate locations that have users working on them via thin-client - (RDP). The users run Outlook 2010 from the three servers. Two of the terminal servers are Windows 2008 R2 and one is 2003 R2 Standard. I am able to get the Outlook clients to connect to Exchange from the two 2008 servers but the Outlook clients on the 2003 server are so far unable to connect to the Exchange server.

When I try to add the mail profile from the control panel - signed on as each user - it auto detects the user profile and looks like it connects but then it prompts for a password. I can try to input the password but it will not accept it. Ultimately it fails with a message indicating Outlook cannot log on etc., etc.

These three servers are at three different locations but connect back to the location where the Exchange server resides via MPLS. Connectivity between locations is solid.

Odd thing is I have an old 2003 server at the same location where the Exchange box is and I fired it up and tried to connect an Outlook client from it and it does not work either.

Does anyone know of any documented problems with connecting to 2013 Exchange from a 2003 server OS? Or, conversely, has anyone successfully deployed Exchange to Outlook clients on a 2003 server?

We have implemented our Exch2013 servers 2 server 1 dag w/ 2 databases. We are using split DNS.

We have only moved over 2 users to the 2013 environment and ran into an issue with Address book not updating. Everything else checks out fine.

What I have found so far is the Autodiscover is not returning an OAB URL.

Test-outlookwebservice gives me this with a verbose:

"VERBOSE: [22:01:59.504 GMT] Test-OutlookWebServices : Autodiscover response:Microsoft.Exchange.Management.Tasks.ServiceValidatorException: The Autodiscover response did not return a URL forOffline Address Book. Response details:"

Get-clientaccessserver shows the autodiscover urls correctly.

Get-offlineaddressbook shows external/internal URls correctly and Webdistriution is enabled.

I have tried removing and rebuilding the autodiscover virtual directory based on some other troubleshooting I have found, but it is still not working.

Any ideas?

I installed Exchange 2013 on windows server 2012. both mail box role and Client access roles are on the same server.

I was trying to setup a local exchange account in outlook 2010 and am getting the following error  once I start outlook "Cannot open your default e-mail folders. You must connect to microsoft Exchange with the current profile before you can synchronize your folder with youroutlook data file (.ost)"

anyone out there with a work around on this

Hi,

It seems they forgot to update ConvertOABVDir.ps1 for Exchange 2013...

All paths and versions refer to Exchange 2010 and not to 2013.

But even changing these paths and versions to reflect the correct ones, IIS throws me error 500 and:

"Could not load file or assembly 'Microsoft.Exchange.OwaUrlModule, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."

Anyone has ever tried do enable Kerberos for outlook in exchange 2013?

Marcelo

# Globals
$setupRegistryPath = Get-ItemProperty -path 'HKLM:SOFTWARE\Microsoft\ExchangeServer\v14\Setup'
$exchangeInstallPath = $setupRegistryPath.MsiInstallPath
$ComputerName = [string]$Env:computername

$OabPath = "Default Web Site/OAB"

# Initialize IIS metabase management object
$InitWebAdmin = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Administration") 
$Iis = new-object Microsoft.Web.Administration.ServerManager 

# Creates OAB app pool based on DefaultAppPool, running as LocalSystem
function CreateOabAppPool
{
    # Get existing OAB authentication values to set later
    $config = $Iis.GetApplicationHostConfiguration();
    $basicAuthenticationSectionEnabled = $config.GetSection("system.webServer/security/authentication/basicAuthentication", "Default Web Site/OAB")["enabled"];
    $windowsAuthenticationSectionEnabled = $config.GetSection("system.webServer/security/authentication/windowsAuthentication", "Default Web Site/OAB")["enabled"];

    $apppool = $Iis.ApplicationPools["MSExchangeOabAppPool"]
    if ($apppool)
    {
        # Delete existing app pool
        $apppool.Delete()       
        # Flush
        $Iis.CommitChanges()
    }

    # Create new app pool, then bind to it
    $a=$Iis.applicationPools.Add("MSExchangeOabAppPool")
    $apppool = $Iis.ApplicationPools["MSExchangeOabAppPool"]
    # Now make sure it runs as LocalSystem, and prevent unnecessary app pool restarts
    $apppool.ProcessModel.IdentityType = [Microsoft.Web.Administration.ProcessModelIdentityType]"LocalSystem"
    $apppool.ProcessModel.idleTimeout = "0.00:00:00"
    $apppool.Recycling.PeriodicRestart.time = "0.00:00:00"

    # Create /OAB application
    $OabApplication = $Iis.Sites["Default Web Site"].Applications["/OAB"]
    if ($OabApplication)
    {
        # Delete it
        $OabApplication.Delete()
        # Flush
        $Iis.CommitChanges()
    }

    $oabvdir=$Iis.Sites["Default Web Site"].Applications["/"].VirtualDirectories["/OAB"]
    if ($oabvdir)
    {
        # Clean up vdir
        $oabvdir.Delete()
        $Iis.CommitChanges()
    }
    $addSite=$Iis.Sites["Default Web Site"].Applications.Add("/OAB", $ExchangeInstallPath + "ClientAccess\OAB")
    $OabApplication = $Iis.Sites["Default Web Site"].Applications["/OAB"]
    if ($OabApplication -eq $Null)
    {
        # Error creating OAB vdir.  Need to fix existing one and rest
        Write-Warning "Error updating Default Web Site/OAB to support the OABAuth component."
        Write-Output "Please use IIS Manager to remove the Default Web Site/OAB virtual directory, then the following commands to recreate the OAB virtual directory:"
        Write-Output "Get-OabVirtualDirectory -server $ComputerName | Remove-OabVirtualDirectory"
        Write-Output "New-OabVirtualDirectory -server $ComputerName"
        break
    }

    #Set app pool
    $OabApplication.ApplicationPoolName = "MSExchangeOabAppPool"

    #Restore previous auth settings and enabled anonymous
    # Reload applicationHost.config
    $config = $Iis.GetApplicationHostConfiguration();
    
    # Check null (inherited from root of web server), otherwise set to previous value
    if ($basicAuthenticationSectionEnabled)
    {
        $basicAuthenticationSection = $config.GetSection("system.webServer/security/authentication/basicAuthentication", "Default Web Site/OAB")
        $basicAuthenticationSection["enabled"]=$basicAuthenticationSectionEnabled
    }
    # Check null (inherited from root of web server), otherwise set to previous value
    if ($windowsAuthenticationSectionEnabled)
    {
        $windowsAuthenticationSection = $config.GetSection("system.webServer/security/authentication/windowsAuthentication", "Default Web Site/OAB")
        $windowsAuthenticationSection["enabled"] = $windowsAuthenticationSectionEnabled
    }

    $Iis.CommitChanges()
}

# Loads OAB auth module by creating or overwriting web.config for OAB vdir
function UpdateOabWebConfig()
{
    $webConfigPath = $ExchangeInstallPath + "ClientAccess\OAB\web.config"
    $webConfigOriginal = @"<?xml version="1.0" encoding="utf-8"?><configuration><system.webServer><modules><add name="Microsoft.Exchange.OABAuth" type="Microsoft.Exchange.OABAuth.OABAuthModule" /></modules></system.webServer><system.web><compilation defaultLanguage="c#" debug="false"><assemblies><add assembly="Microsoft.Exchange.Net, Version=14.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35"/><add assembly="Microsoft.Exchange.Diagnostics, Version=14.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35"/><add assembly="Microsoft.Exchange.OabAuthModule, Version=14.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35"/></assemblies></compilation></system.web><runtime><assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><dependentAssembly><assemblyIdentity name="Microsoft.Exchange.OABAuthModule" publicKeyToken="31bf3856ad364e35" culture="neutral" /><codeBase version="14.0.0.0" href="file:///{0}bin\Microsoft.Exchange.OABAuthModule.dll"/></dependentAssembly><dependentAssembly><assemblyIdentity name="Microsoft.Exchange.Net" publicKeyToken="31bf3856ad364e35" culture="neutral" /><codeBase version="14.0.0.0" href="file:///{0}bin\Microsoft.Exchange.Net.dll"/></dependentAssembly><dependentAssembly><assemblyIdentity name="Microsoft.Exchange.Rpc" publicKeyToken="31bf3856ad364e35" culture="neutral" /><codeBase version="14.0.0.0" href="file:///{0}bin\Microsoft.Exchange.Rpc.dll"/></dependentAssembly><dependentAssembly><assemblyIdentity name="Microsoft.Exchange.Diagnostics" publicKeyToken="31bf3856ad364e35" culture="neutral" /><codeBase version="14.0.0.0" href="file:///{0}bin\Microsoft.Exchange.Diagnostics.dll"/></dependentAssembly></assemblyBinding></runtime></configuration>"@
    # Swap in Exchange installation path
    $webConfigData = [string]::Format($webConfigOriginal, $ExchangeInstallPath)

    # Check for existing web.config
    if (Test-Path $webConfigPath)
    {
        # Make a backup copy of current web.config
        $backupPath = $webConfigPath + " Backup " + [string](get-date -Format "yyyy-MM-dd HHmmss")
        Write-Output "Backing up existing web.config to ""$backupPath"""
        Copy-Item $webConfigPath $backupPath
    }
    Out-File -FilePath $webConfigPath -InputObject $webConfigData -Encoding "UTF8"
    Write-Output "Created $webConfigPath."
}


# Main
Write-Output "Converting OAB virtual directory on $ComputerName to an application..." ""

# Get IIS config to create OAB-specific app pool, then add web.config for OABAuth module
UpdateOabWebConfig
CreateOabAppPool

Write-Output "Done!  OAB virtual directory has been converted to an application on $ComputerName."
$a=$Iis.Dispose()

# SIG # Begin signature block
# MIIaqwYJKoZIhvcNAQcCoIIanDCCGpgCAQExCzAJBgUrDgMCGgUAMGkGCisGAQQB
# gjcCAQSgWzBZMDQGCisGAQQBgjcCAR4wJgIDAQAABBAfzDtgWUsITrck0sYpfvNR
# AgEAAgEAAgEAAgEAAgEAMCEwCQYFKw4DAhoFAAQU9/hTOMuPNFNowKeSrS1Unzot
# K86gghV5MIIEujCCA6KgAwIBAgIKYQKOQgAAAAAAHzANBgkqhkiG9w0BAQUFADB3
# MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3RvbjEQMA4GA1UEBxMHUmVk
# bW9uZDEeMBwGA1UEChMVTWljcm9zb2Z0IENvcnBvcmF0aW9uMSEwHwYDVQQDExhN
# aWNyb3NvZnQgVGltZS1TdGFtcCBQQ0EwHhcNMTIwMTA5MjIyNTU4WhcNMTMwNDA5
# MjIyNTU4WjCBszELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAO
# BgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEN
# MAsGA1UECxMETU9QUjEnMCUGA1UECxMebkNpcGhlciBEU0UgRVNOOkY1MjgtMzc3
# Ny04QTc2MSUwIwYDVQQDExxNaWNyb3NvZnQgVGltZS1TdGFtcCBTZXJ2aWNlMIIB
# IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAluyOR01UwlyVgNdOCz2/l0PD
# S+NgZxEvAU0M2NFGLxBA3gukUFISiAtDei0/7khuZseR5gPKbux5qWojm81ins1q
# pD/no0P/YkehtLpE+t9AwYVUfuigpyxDI5tSHzI19P6aVp+NY3d7MJ4KM4VyG8pK
# yMwlzdtdES7HsIzxj0NIRwW1eiAL5fPvwbr0s9jNOI/7Iao9Cm2FF9DK54YDwDOD
# tSXEzFqcxMPaYiVNUyUUYY/7G+Ds90fGgEXmNVMjNnfKsN2YKznAdTUP3YFMIT12
# MMWysGVzKUgn2MLSsIRHu3i61XQD3tdLGfdT3njahvdhiCYztEfGoFSIFSssdQID
# AQABo4IBCTCCAQUwHQYDVR0OBBYEFC/oRsho025PsiDQ3olO8UfuSMHyMB8GA1Ud
# IwQYMBaAFCM0+NlSRnAK7UD7dvuzK7DDNbMPMFQGA1UdHwRNMEswSaBHoEWGQ2h0
# dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9wa2kvY3JsL3Byb2R1Y3RzL01pY3Jvc29m
# dFRpbWVTdGFtcFBDQS5jcmwwWAYIKwYBBQUHAQEETDBKMEgGCCsGAQUFBzAChjxo
# dHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY3Jvc29mdFRpbWVT
# dGFtcFBDQS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwgwDQYJKoZIhvcNAQEFBQAD
# ggEBAHP/fS6dzY2IK3x9414VceloYvAItkNWxFxKLWjY+UgRkfMRnIXsEtRUoHWp
# OKFZf3XuxvU02FSk4tDMfJerk3UwlwcdBFMsNn9/8UAeDJuA4hIKIDoxwAd1Z+D6
# NJzsiPtXHOVYYiCQRS9dRanIjrN8cm0QJ8VL2G+iqBKzbTUjZ/os2yUtuV2xHgXn
# Qyg+nAV2d/El3gVHGW3eSYWh2kpLCEYhNah1Nky3swiq37cr2b4qav3fNRfMPwzH
# 3QbPTpQkYyALLiSuX0NEEnpc3TfbpEWzkToSV33jR8Zm08+cRlb0TAex4Ayq1fbV
# PKLgtdT4HH4EVRBrGPSRzVGnlWUwggTsMIID1KADAgECAhMzAAAAsBGvCovQO5/d
# AAEAAACwMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpX
# YXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMR4wHAYDVQQKExVNaWNyb3NvZnQg
# Q29ycG9yYXRpb24xIzAhBgNVBAMTGk1pY3Jvc29mdCBDb2RlIFNpZ25pbmcgUENB
# MB4XDTEzMDEyNDIyMzMzOVoXDTE0MDQyNDIyMzMzOVowgYMxCzAJBgNVBAYTAlVT
# MRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMR4wHAYDVQQK
# ExVNaWNyb3NvZnQgQ29ycG9yYXRpb24xDTALBgNVBAsTBE1PUFIxHjAcBgNVBAMT
# FU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
# AQoCggEBAOivXKIgDfgofLwFe3+t7ut2rChTPzrbQH2zjjPmVz+lURU0VKXPtIup
# P6g34S1Q7TUWTu9NetsTdoiwLPBZXKnr4dcpdeQbhSeb8/gtnkE2KwtA+747urlc
# dZMWUkvKM8U3sPPrfqj1QRVcCGUdITfwLLoiCxCxEJ13IoWEfE+5G5Cw9aP+i/QM
# mk6g9ckKIeKq4wE2R/0vgmqBA/WpNdyUV537S9QOgts4jxL+49Z6dIhk4WLEJS4q
# rp0YHw4etsKvJLQOULzeHJNcSaZ5tbbbzvlweygBhLgqKc+/qQUF4eAPcU39rVwj
# gynrx8VKyOgnhNN+xkMLlQAFsU9lccUCAwEAAaOCAWAwggFcMBMGA1UdJQQMMAoG
# CCsGAQUFBwMDMB0GA1UdDgQWBBRZcaZaM03amAeA/4Qevof5cjJB8jBRBgNVHREE
# SjBIpEYwRDENMAsGA1UECxMETU9QUjEzMDEGA1UEBRMqMzE1OTUrNGZhZjBiNzEt
# YWQzNy00YWEzLWE2NzEtNzZiYzA1MjM0NGFkMB8GA1UdIwQYMBaAFMsR6MrStBZY
# Ack3LjMWFrlMmgofMFYGA1UdHwRPME0wS6BJoEeGRWh0dHA6Ly9jcmwubWljcm9z
# b2Z0LmNvbS9wa2kvY3JsL3Byb2R1Y3RzL01pY0NvZFNpZ1BDQV8wOC0zMS0yMDEw
# LmNybDBaBggrBgEFBQcBAQROMEwwSgYIKwYBBQUHMAKGPmh0dHA6Ly93d3cubWlj
# cm9zb2Z0LmNvbS9wa2kvY2VydHMvTWljQ29kU2lnUENBXzA4LTMxLTIwMTAuY3J0
# MA0GCSqGSIb3DQEBBQUAA4IBAQAx124qElczgdWdxuv5OtRETQie7l7falu3ec8C
# nLx2aJ6QoZwLw3+ijPFNupU5+w3g4Zv0XSQPG42IFTp8263Os8lsujksRX0kEVQm
# MA0N/0fqAwfl5GZdLHudHakQ+hywdPJPaWueqSSE2u2WoN9zpO9qGqxLYp7xfMAU
# f0jNTbJE+fA8k21C2Oh85hegm2hoCSj5ApfvEQO6Z1Ktwemzc6bSY81K4j7k8079
# /6HguwITO10g3lU/o66QQDE4dSheBKlGbeb1enlAvR/N6EXVruJdPvV1x+ZmY2DM
# 1ZqEh40kMPfvNNBjHbFCZ0oOS786Du+2lTqnOOQlkgimiGaCMIIFvDCCA6SgAwIB
# AgIKYTMmGgAAAAAAMTANBgkqhkiG9w0BAQUFADBfMRMwEQYKCZImiZPyLGQBGRYD
# Y29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0MS0wKwYDVQQDEyRNaWNyb3Nv
# ZnQgUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTAwODMxMjIxOTMyWhcN
# MjAwODMxMjIyOTMyWjB5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3Rv
# bjEQMA4GA1UEBxMHUmVkbW9uZDEeMBwGA1UEChMVTWljcm9zb2Z0IENvcnBvcmF0
# aW9uMSMwIQYDVQQDExpNaWNyb3NvZnQgQ29kZSBTaWduaW5nIFBDQTCCASIwDQYJ
# KoZIhvcNAQEBBQADggEPADCCAQoCggEBALJyWVwZMGS/HZpgICBCmXZTbD4b1m/M
# y/Hqa/6XFhDg3zp0gxq3L6Ay7P/ewkJOI9VyANs1VwqJyq4gSfTwaKxNS42lvXlL
# cZtHB9r9Jd+ddYjPqnNEf9eB2/O98jakyVxF3K+tPeAoaJcap6Vyc1bxF5Tk/TWU
# cqDWdl8ed0WDhTgW0HNbBbpnUo2lsmkv2hkL/pJ0KeJ2L1TdFDBZ+NKNYv3LyV9G
# MVC5JxPkQDDPcikQKCLHN049oDI9kM2hOAaFXE5WgigqBTK3S9dPY+fSLWLxRT3n
# rAgA9kahntFbjCZT6HqqSvJGzzc8OJ60d1ylF56NyxGPVjzBrAlfA9MCAwEAAaOC
# AV4wggFaMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFMsR6MrStBZYAck3LjMW
# FrlMmgofMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQB
# gjcVAgQWBBT90TFO0yaKleGYYDuoMW+mPLzYLTAZBgkrBgEEAYI3FAIEDB4KAFMA
# dQBiAEMAQTAfBgNVHSMEGDAWgBQOrIJgQFYnl+UlE/wq4QpTlVnkpDBQBgNVHR8E
# STBHMEWgQ6BBhj9odHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9k
# dWN0cy9taWNyb3NvZnRyb290Y2VydC5jcmwwVAYIKwYBBQUHAQEESDBGMEQGCCsG
# AQUFBzAChjhodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY3Jv
# c29mdFJvb3RDZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAgEAWTk+fyZGr+tvQLEy
# tWrrDi9uqEn361917Uw7LddDrQv+y+ktMaMjzHxQmIAhXaw9L0y6oqhWnONwu7i0
# +Hm1SXL3PupBf8rhDBdpy6WcIC36C1DEVs0t40rSvHDnqA2iA6VW4LiKS1fylUKc
# 8fPv7uOGHzQ8uFaa8FMjhSqkghyT4pQHHfLiTviMocroE6WRTsgb0o9ylSpxbZsa
# +BzwU9ZnzCL/XB3Nooy9J7J5Y1ZEolHN+emjWFbdmwJFRC9f9Nqu1IIybvyklRPk
# 62nnqaIsvsgrEA5ljpnb9aL6EiYJZTiU8XofSrvR4Vbo0HiWGFzJNRZf3ZMdSY4t
# vq00RBzuEBUaAF3dNVshzpjHCe6FDoxPbQ4TTj18KUicctHzbMrB7HCjV5JXfZSN
# oBtIA1r3z6NnCnSlNu0tLxfI5nI3EvRvsTxngvlSso0zFmUeDordEN5k9G/ORtTT
# F+l5xAS00/ss3x+KnqwK+xMnQK3k+eGpf0a7B2BHZWBATrBC7E7ts3Z52Ao0CW0c
# gDEf4g5U3eWh++VHEK1kmP9QFi58vwUheuKVQSdpw5OPlcmN2Jshrg1cnPCiroZo
# gwxqLbt2awAdlq3yFnv2FoMkuYjPaqhHMS+a3ONxPdcAfmJH0c6IybgY+g5yjcGj
# Pa8CQGr/aZuW4hCoELQ3UAjWwz0wggYHMIID76ADAgECAgphFmg0AAAAAAAcMA0G
# CSqGSIb3DQEBBQUAMF8xEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/Is
# ZAEZFgltaWNyb3NvZnQxLTArBgNVBAMTJE1pY3Jvc29mdCBSb290IENlcnRpZmlj
# YXRlIEF1dGhvcml0eTAeFw0wNzA0MDMxMjUzMDlaFw0yMTA0MDMxMzAzMDlaMHcx
# CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRt
# b25kMR4wHAYDVQQKExVNaWNyb3NvZnQgQ29ycG9yYXRpb24xITAfBgNVBAMTGE1p
# Y3Jvc29mdCBUaW1lLVN0YW1wIFBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
# AQoCggEBAJ+hbLHf20iSKnxrLhnhveLjxZlRI1Ctzt0YTiQP7tGn0UytdDAgEesH
# 1VSVFUmUG0KSrphcMCbaAGvoe73siQcP9w4EmPCJzB/LMySHnfL0Zxws/HvniB3q
# 506jocEjU8qN+kXPCdBer9CwQgSi+aZsk2fXKNxGU7CG0OUoRi4nrIZPVVIM5AMs
# +2qQkDBuh/NZMJ36ftaXs+ghl3740hPzCLdTbVK0RZCfSABKR2YRJylmqJfk0waB
# SqL5hKcRRxQJgp+E7VV4/gGaHVAIhQAQMEbtt94jRrvELVSfrx54QTF3zJvfO4OT
# oWECtR0Nsfz3m7IBziJLVP/5BcPCIAsCAwEAAaOCAaswggGnMA8GA1UdEwEB/wQF
# MAMBAf8wHQYDVR0OBBYEFCM0+NlSRnAK7UD7dvuzK7DDNbMPMAsGA1UdDwQEAwIB
# hjAQBgkrBgEEAYI3FQEEAwIBADCBmAYDVR0jBIGQMIGNgBQOrIJgQFYnl+UlE/wq
# 4QpTlVnkpKFjpGEwXzETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixk
# ARkWCW1pY3Jvc29mdDEtMCsGA1UEAxMkTWljcm9zb2Z0IFJvb3QgQ2VydGlmaWNh
# dGUgQXV0aG9yaXR5ghB5rRahSqClrUxzWPQHEy5lMFAGA1UdHwRJMEcwRaBDoEGG
# P2h0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9wa2kvY3JsL3Byb2R1Y3RzL21pY3Jv
# c29mdHJvb3RjZXJ0LmNybDBUBggrBgEFBQcBAQRIMEYwRAYIKwYBBQUHMAKGOGh0
# dHA6Ly93d3cubWljcm9zb2Z0LmNvbS9wa2kvY2VydHMvTWljcm9zb2Z0Um9vdENl
# cnQuY3J0MBMGA1UdJQQMMAoGCCsGAQUFBwMIMA0GCSqGSIb3DQEBBQUAA4ICAQAQ
# l4rDXANENt3ptK132855UU0BsS50cVttDBOrzr57j7gu1BKijG1iuFcCy04gE1CZ
# 3XpA4le7r1iaHOEdAYasu3jyi9DsOwHu4r6PCgXIjUji8FMV3U+rkuTnjWrVgMHm
# lPIGL4UD6ZEqJCJw+/b85HiZLg33B+JwvBhOnY5rCnKVuKE5nGctxVEO6mJcPxaY
# iyA/4gcaMvnMMUp2MT0rcgvI6nA9/4UKE9/CCmGO8Ne4F+tOi3/FNSteo7/rvH0L
# QnvUU3Ih7jDKu3hlXFsBFwoUDtLaFJj1PLlmWLMtL+f5hYbMUVbonXCUbKw5TNT2
# eb+qGHpiKe+imyk0BncaYsk9Hm0fgvALxyy7z0Oz5fnsfbXjpKh0NbhOxXEjEiZ2
# CzxSjHFaRkMUvLOzsE1nyJ9C/4B5IYCeFTBm6EISXhrIniIh0EPpK+m79EjMLNTY
# MoBMJipIJF9a6lbvpt6Znco6b72BJ3QGEe52Ib+bgsEnVLaxaj2JoXZhtG6hE6a/
# qkfwEm/9ijJssv7fUciMI8lmvZ0dhxJkAj0tr1mPuOQh5bWwymO0eFQF1EEuUKyU
# sKV4q7OglnUa2ZKHE3UiLzKoCG6gW4wlv6DvhMoh1useT8ma7kng9wFlb4kLfchp
# yOZu6qeXzjEp/w7FW1zYTRuh2Povnj8uVRZryROj/TGCBJwwggSYAgEBMIGQMHkx
# CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRt
# b25kMR4wHAYDVQQKExVNaWNyb3NvZnQgQ29ycG9yYXRpb24xIzAhBgNVBAMTGk1p
# Y3Jvc29mdCBDb2RlIFNpZ25pbmcgUENBAhMzAAAAsBGvCovQO5/dAAEAAACwMAkG
# BSsOAwIaBQCggb4wGQYJKoZIhvcNAQkDMQwGCisGAQQBgjcCAQQwHAYKKwYBBAGC
# NwIBCzEOMAwGCisGAQQBgjcCARUwIwYJKoZIhvcNAQkEMRYEFF0zL6v/FHt2Mc6N
# GK0kb8qQgKOdMF4GCisGAQQBgjcCAQwxUDBOoCaAJABDAG8AbgB2AGUAcgB0AE8A
# QQBCAFYARABpAHIALgBwAHMAMaEkgCJodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20v
# ZXhjaGFuZ2UgMA0GCSqGSIb3DQEBAQUABIIBAH4LW8iYUwQqH1FlIF88XbHxcE02
# g9Tikg7amI4NUYJqE8VRIgWrwjZr8jXCa4Fi74Xmm/XSHqI4CtXi4Ue9I9MqrE/7
# iON55uPlaBtyPiCOU9C3QrEoBp3ThMm2MDP/HVJLxh6H20fcnD32Ey2pc1njB0rb
# zpem/yVKO24EG4ksUYbFSX8LqV55C0xZfpi3TKtAk0xeWZX7vNG2BN2UlhGa0gVQ
# RKr8VraT7bCiWMhG1efX/O6I4c8Ycf2OB1+u015Bph9BQTMLOal4RrvNJRaZdAro
# HDBYXeihk/5bdoNad54CWq/5jvpQB8j1ItTZFLI/8/2oRzHPyhDudP11o4qhggIf
# MIICGwYJKoZIhvcNAQkGMYICDDCCAggCAQEwgYUwdzELMAkGA1UEBhMCVVMxEzAR
# BgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1p
# Y3Jvc29mdCBDb3Jwb3JhdGlvbjEhMB8GA1UEAxMYTWljcm9zb2Z0IFRpbWUtU3Rh
# bXAgUENBAgphAo5CAAAAAAAfMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJ
# KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMjkwMzE3NTFaMCMGCSqGSIb3
# DQEJBDEWBBQdvnILmIidnC1R04O3l6CRVLXvzjANBgkqhkiG9w0BAQUFAASCAQCE
# 3AJJUr0bDBqmyFsak1VUtHBs+9mB3O1cmSrVYRRMuMNQnIAyOKrv9eXdkSZJZGnQ
# suQ+RwP12Ox1K6T6JaqeonVBUaZW6ZYv73e4NhdWDF8Im5xX2q6FJ/bs50nwHx/a
# boBfCU9hTAjoKML3hnY5plMeulkVJ7xXGibN5zGUV49ovgRt4xAWrWo9I7pUsyh1
# 7f8gfT0N96LWL8PnDlvfSAqIytGTh3k/HwBywqAP+dj36Nj3+j27giFQSPk8qDIJ
# QoMYR4MJrSexDVeqDrkmNY9fm7HvydCZZWH1WGAOZ6oxLOEDD3lQYPEI62qbZHy4
# Ry2kqdKtWHssVPS7danp
# SIG # End signature block

Marcelo

Hello All:

This is a moved post for follow up for maybe something on Exchange stopping S/MIME. http://answers.microsoft.com/en-us/office/forum/office_2010-outlook/outlook-2010-smime-problems/28bcd32f-51f7-4c42-b94e-e59862a76ce7