Exchange 2010 SP3 installation fails on SBS 2011


I had an interesting issue with Exchange 2010 SP3 installation on a SBS 2011 server last night. Installation fails on the Hub Transport Server Role with following errors.

sbs 2011 upgrade sp3 error

 

This made me scratching my head. Why is it trying to remove existing certificate that is used by Exchange? It’s also the default SMTP certificate, that’s why setup was not able to remove it.

After investing further, I see this line in the PowerShell script,

Write-ExchangeSetupLog -Info “Removing default Exchange Certificate”;
Get-ExchangeCertificate | where {$_.FriendlyName.ToString() -eq “Microsoft Exchange”} | Remove-ExchangeCertificate

So it’s trying to remove default Exchange certificate that was created during the initial installation, that has friendly name “Microsoft Exchange”.

I’m thinking, there is no way the Godaddy certificate has Friendly Name “Microsoft Exchange”. After looking at the certificate properties, it is indeed the problem. The Friendly Name is showing “Microsoft Exchange”, instead of mail.domain.com.

In order for us to install SP3, we have to use SBS console to import a temporary certificate, so it updates “LeafCertThumbPrint” property in this registry key,

“HKEY_LOCAL_MACHINE\Software\Microsoft\SmallBusinessServer\Networking”

 Note: you can also update the registry manually with one of thumbprint from existing certificate that is already imported.

Exchange 2010 SP3 installs fine after the cert change.  Since we didn’t export the existing GoDaddy certificate before running SP3 setup, it was removed by the setup. In order for Exchange OA and Activesync clients  to continue function,  we have issue a new certificate request with proper Friendly Name, then import the new certificate. You can also reuse the existing certificate on GoDaddy’s website by using “Re-Key” option, but you might end up with a certificate without private key. To repair the missing private key, you can run following command
   certutil –repairstore my <serial number>

 

 

Connecting to Lync Online


Issue when connecting to Lync Online you may receive one of the the following errors

“The ‘New-CsOnlineSession’ command was found in the module ‘LyncOnlineConnector’, but
the module could not be loaded. For more information, run ‘Import-Module LyncOnlineConnector’.”

and

“Unable to discover PowerShell endpoing URI
At C:\Program Files\Common Files\Microsoft Lync Server
2013\Modules\LyncOnlineConnector\LyncOnlineConnectorStartup.psm1”

 

Lets deal with the first one,:

First ensure you have downloaded and installed the Powershell Module for Lync Online

Next, and this is the weird part set the powershell execution policy to “unrestricted”, is seems there is an issue with the modules loading, we were able to discover this by comparing a powershell session for one system that worked and other that did not. (if you are security conscious you may want to set this back when you are done)
The specific command is set-ExecutionPolicy unrestricted

For the last error ensure you have configured your Lyncdiscover records in your External DNS, this is needed for powershell to detect and connect to your online Lync environment, if you are in a hybrid configuration you may be pointing this to on-prem Lync and not Lync online. you can find your specific configuration by clicking on your domain in the office 365 admin center.

Finally the syntax to connect to your Lync Online is:esco over anything in particular let

$LiveCred = Get-Credential
$LyncSession = New-CsOnlineSession -Credential $livecred
Import-PSSession $LyncSession

Unable to open Local Windows Backup Snap-in.


A fatal error occured during a Windows Server Backup Snap-in (wbadmin.msc) operation. Error details: the Windows Server Backup service has stopped. Close wbadmin.msc and then restart it

Background:

  • I had installed the beta version of Microsoft online backup
  • I had backed up locally to a USB drive that has since failed
  • Backups were scheduled locally and to the online backup service.
  • When I removed the online beta backup software (Now Azure) and my failed drive, I was no longer able to manage windows backup from the GUI.

This is the error I received in the event log.

Event ID 1000
Source Application Error

Faulting application name: wbengine.exe, version: 6.2.9200.16384, time stamp: 0x50108cb6
Faulting module name: wbengine.exe, version: 6.2.9200.16384, time stamp: 0x50108cb6
Exception code: 0xc0000005
Fault offset: 0x000000000012623a
Faulting process id: 0x2678
Faulting application start time: 0x01ce64c42da7256f
Faulting application path: C:\Windows\system32\wbengine.exe
Faulting module path: C:\Windows\system32\wbengine.exe
Report Id: 6c2d3105-d0b7-11e2-9415-c86000003091
Faulting package full name:
Faulting package-relative application ID:

Cause:

I had backups placed on a failed drive, this was causing the backup software to crash when it tried to enumerate them. (Not that the error or events point to that at all!)

Resolution:

I ran the following PowerShell cmtlets and re-setup my backups (Caution this will remove all record of any backup have taken place!!)

    1. Get-WBPolicy | Remove-WBPolicy
    2. Remove-WBBackupSet
    3. Remove-WBCatalog
    4. get-Service *wb* | Start-Service
    5. Restart Windows Server Backup

Sweet! may backup works again!

Note: I was also able to re-download the Azure Backup agent and that is now working like a charm as well.

Creating Custom DLP Classification Rules and Policy


When at first I was looking into this the TechNet documentation was extensive and yet not as specific as I would prefer, so here is the quick and dirty DLP classification!

Creating and importing custom Classifications

  1. First you need to create your custom policy XML (Example Below)
  2. Save as XML Unicode file type (C:\MyNewPolicy.xml)
  3. Open the XML in internet explorer if its formatted correctly you will see the XML.
  4. Then import with Powershell
    New-ClassificationRuleCollection –FileData ([Byte[]]$(Get-Content -path C:\MyNewPolicy.xml -Encoding byte -ReadCount 0))
  5. Once its imported you should be able to create a new DLP policy using the EAC

Creating a custom DLP Rule

  1. Login to EAC (i.e https://mail.domain.com/ecp)
  2. Click Compliance Management, data loss prevention
  3. Click the Plusimage , then New custom policy
    image
  4. Name your policy and Choose your mode (I like to test with Policy tags), and click Save
    image
  5. Select the policy and click the image edit your new policy
  6. Select Rules from the left
  7. Click the imageto Create a new rule
  8. On the Apply this rule if field choose The message contains Sensitive information..
  9. Click *Select sensitive information types….. (if applicable)
  10. Click the imageto choose from the list,
  11. You should now see your new classification (from the example below it would be Secure Product Codes\ DLP by Exchangemasters.info)

image

Useful Tools

Example of a Rule Classification XML

 <?xml version=”1.0″ encoding=”utf-16″?>

 <RulePackage xmlns=”http://schemas.microsoft.com/office/2011/mce”&gt;

 <RulePack id=”b4b4c60e-2ff7-47b2-a672-86e36cf608be”>

  <Version major=”1″ minor=”0″ build=”0″ revision=”0″/>

  <Publisher id=”7ea13c35-0e58-472a-b864-5f2e717edec6″/>

  <Details defaultLangCode=”en-us”>

  <LocalizedDetails langcode=”en-us”>

  <PublisherName>DLP by Exchangemasters.info</PublisherName>

  <Name>Secure Product Codes</Name>

  <Description>Secure Products</Description>

  </LocalizedDetails>

  </Details>

  </RulePack>

  <Rules>

  <!– Product Code –>

  <Entity id=”acc59528-ff01-433e-aeee-13ca8aaee159″ patternsProximity=”300″ recommendedConfidence=”75″>

 <Pattern confidenceLevel=”75″>

  <IdMatch idRef=”Regex_Product_Code” />

  <Match idRef=”Code” />

  </Pattern>

  </Entity>

  <Regex id=”Regex_Product_Code”>[A-Z]{3}[0-9]{9}

  </Regex>

  <Keyword id=”Code”>

  <Group matchStyle=”word”>

  <Term>Code</Term>

  </Group>

  </Keyword>

  <LocalizedStrings>

  <Resource idRef=”acc59528-ff01-433e-aeee-13ca8aaee159″>

  <Name default=”true” langcode=”en-us”>

  Product Code

  </Name>

  <Description default=”true” langcode=”en-us”>

 A custom classification for detecting product codes that have 3 uppercase letters and 9 numbers

 </Description>

 </Resource>

</LocalizedStrings>

</Rules>

</RulePackage>

Checking for Open Relay in Exchange 2007/2010


Scenario:

So this is a fairly common scenario & I figured I’d post an easy method to diagnose the issue. Customers will often suspect that they’re an open relay due to being placed on a blacklist or having issues sending email to certain domains. There’s some general confusion as to what constitutes as an Open Relay & even the difference between a Relay & a Submit action in SMTP terminology. Hopefully this can clear some of the confusion.

Background:

Submit = Submitting an email message to an SMTP server that is destined for a domain that exists on that server (or in that server’s environment). You’re sending it to an address that the server is authoritative for.

Relay = Submitting an email message to an SMTP server that is destined for a domain that exists in another messaging environment. You’re sending to an address that the server is not authoritative for.

So there’s nothing inherently wrong with relaying. It’s what happens if you use your Hotmail account to send an email to someone’s Gmail account. It happens every time you email someone outside of your own messaging system. The key detail is whether or not you have authenticated to the SMTP server beforehand. So when you’re using Hotmail or Exchange via Outlook/OWA then you have obviously authenticated either via an Authentication Prompt, OWA Form, or using NTLM.

So this typically comes up when a customer needs to have an application, network printer, or other device be able to send emails through Exchange (or any internal SMTP server).

So the important thing to point out here is that as long as the application/device only needs to be able to send to addresses that your SMTP server is authoritative for then it is a Submit action & not a Relay action. This just means you only need it to be able to hit a Receive Connector that allows Anonymous Submit; which is how most of the world’s SMTP servers are configured to accept email from the Internet.

However, if your application/device needs to be able to send to an address not under the authority of the local SMTP server then it will be performing an SMTP Relay action & will require additional configuration.

The recommended approach is to have the Application/Device authenticate to your SMTP server if it supports it. Alternatively, you can configure the Receive Connector (Exchange) to allow Anonymous Relaying from that Application/Device’s IP address.

For instructions please see this Microsoft Post.

http://blogs.technet.com/b/exchange/archive/2006/12/28/3397620.aspx

This is a very common issue amongst customers because they may not be familiar with how to configure this. However, unfortunately I will often see customers make an even worse mistake; allowing Anonymous Relaying from an entire range of IP Addresses or possibly the entire Internet. It won’t take long for Internet folks with malicious intent to figure this out & start using your server to SPAM whoever they wish. This typically results in your Exchange Server’s sending IP being placed on various Blacklists which can prevent you from sending to certain email domains.

Resolution:

It is ALWAYS recommended to create a separate Receive Connector for this purpose. In fact I tell customers to never mess with the Default Receive Connectors if they can get away with it. But what will ultimately happen is the customer will use the steps in the Microsoft article above to enable Anonymous Relaying on their Default Receive Connector instead, which they’re probably also using as their Internet ingress point. The problem with this is that the Remote IP range of that connector is 0.0.0.0-255.255.255.255 out of the box; meaning the entire Internet.

Another thing the customer might do is create a new Receive Connector for Relaying but instead of just having 1 IP address in there (the IP of their Application Server or Network Device) they’ll add an entire range or more IPs than are needed. This can get pretty complicated to troubleshoot if you have many different Receive Connectors on many different Exchange Servers in the environment.

So I’m hoping people can use my explanation to help them configure this properly as well as troubleshoot any issues they may have. In addition to that, here’s a very useful command to use in Exchange Management Shell to list out all Receive Connectors in the environment that have the Anonymous Relay permission enabled. Use this to track these connectors down & then verify the RemoteIP Ranges are properly scoped/configured to be as secure as possible.

Get-ReceiveConnector | Get-ADPermission -User “NT Authority\Anonymous Logon” | Where-Object {$_.ExtendedRights -like “ms-Exch-SMTP-Accept-Any-Recipient”} | Format-List Identity,ExtendedRights

Exchange 2010 Powershell Lab Tools


Recently a good friend of mine pointed out some great tools that Mike Pfeiffer posted and I have to say they are pretty awesome and I would recommend checking them out.

Populating Exchange Labs with Mailboxes using PowerShell

Provision Exchange Mailboxes from CSV using PowerShell Advanced Functions

Generating Test Email Data for Exchange Labs with PowerShell

Can’t run Tracking Log Explorer : Access Denied


 

Issue: User is a standard user (not a domain admin) and his RBAC permissions allow him to do message tracking but he is not not an Organization Admin.

  • Running with Exchange PowerShell (get-messagetrackinglog): works
  • Running with ECP: works
  • Running with Tracking Log Explorer : Broken

“Failed to connect to the Microsoft Exchange Transport Log Search service on computer “Exchange_Servername”. Verify that a valid computer name was used and the Microsoft Exchange Transport Log Search service is started on the target computer.” The error message is: Access is denied.”

image

Reason: EXTra.exe is what is used to run Tracking Log Explorer and it doesn’t use remote PowerShell therefore your permissions are based on  your AD login permissions not RBAC.

Solutions:

    1. Add the users to the “Exchange View-Only Administrators” (2007) or “Public Folder Management” (2010 Green Field) AD Group to be able to use the GUI.
    2. Use Exchange PowerShell or ECP to pull the tracking logs.

Thanks to Andrew and Ron for Figuring this out!

Note: Walkthrough on setting up ECP\ EMS Message tracking access