Configuring the Edge Server

Configure the Accepted Domains

1. New-AcceptedDomain -Name service.contoso.com -DomainName service.contoso.com -DomainType ExternalRelay
2. New-AcceptedDomain -Name contoso.com -DomainName contoso.com -DomainType Authoritative

Configure the Remote Domains

1. New-RemoteDomain "Inbound Remote Domain" -DomainName contoso.com
2. New-RemoteDomain "Outbound Remote Domain" -DomainName service.contoso.com
3. Set-RemoteDomain "Inbound Remote Domain" -TrustedMailInboundEnabled $True
4. Set-RemoteDomain "Outbound Remote Domain" -TrustedMailOutboundEnabled $True -TargetDeliveryDomain $True

Configure the Receive Connector

1. New-ReceiveConnector -Name "From Hub" -AuthMechanism ExternalAuthoritative -Fqdn mail.contoso.com -PermissionGroups AnonymousUsers,ExchangeServers,Partners -TlsDomainCapabilities mail.contoso.com:AcceptOorgProtocol -RemoteIPRanges <IP Address of Hub> -Bindings 0.0.0.0:25
2. New-ReceiveConnector -Name "From Cloud" -Usage Internet -RemoteIPRanges <FOPE Outbound IP Addresses> -Bindings 0.0.0.0:25 -FQDN mail.contoso.com -TlsDomainCapabilities mail.messaging.microsoft.com:AcceptOorgProtocol
   1. FOPE IPS as of 11/08/11
      1. 12.129.20.0/24,12.129.199.61,12.129.219.155,63.241.222.0/24,65.55.88.0/24,94.245.120.64/26,206.16.57.70,207.46.51.64/26,207.46.163.0/24,213.199.154.0/24,213.199.180.128/26,216.32.180.0/24,216.32.181.0/24

Configure the Send Connector

1. New-SendConnector "To Cloud" -RequireTLS $True -TlsAuthLevel DomainValidation -TlsDomain mail.messaging.microsoft.com -Fqdn mail.contoso.com -ErrorPolicies DowngradeAuthFailures -AddressSpaces SMTP:service.contoso.com
2. New-SendConnector -Name "To Hub" -AddressSpaces SMTP:contoso.com -Fqdn mail.contoso.com -SmartHosts <IP Address of HUB> -UseExternalDNSServersEnabled $false -SmartHostAuthMechanism ExternalAuthoritative
   

Configuring the Hub Transport Server

Configure the Remote Domains

1. New-RemoteDomain "Inbound Remote Domain" -DomainName contoso.com
2. New-RemoteDomain "Outbound Remote Domain" -DomainName service.contoso.com
3. Set-RemoteDomain "Inbound Remote Domain" -TrustedMailInboundEnabled $True
4. Set-RemoteDomain "Outbound Remote Domain" -TrustedMailOutboundEnabled $True -TargetDeliveryDomain $True -AllowedOOFType InternalLegacy -AutoReplyEnabled $True -AutoForwardEnabled $True -DeliveryReportEnabled $True -NDREnabled $True -DisplaySenderName $True -TNEFEnabled $True

Configure the Receive Connector

1. New-ReceiveConnector -Name "From Edge" -AuthMechanism ExternalAuthoritative -Fqdn mail.contoso.com -PermissionGroups ExchangeServers -RemoteIPRanges <IP Address from EDGE> -Bindings 0.0.0.0:25

Configure the Send Connector

1. New-SendConnector -Name "To Edge" -AddressSpaces SMTP:service.contoso.com -Fqdn mail.contoso.com -SmartHosts <IP Address of EDGE> -UseExternalDNSServersEnabled $false -SmartHostAuthMechanism ExternalAuthoritative

# Active Sync Log Directory
$ActiveSyncLogDirectory = "C:\Inetpub\Logs\LogFiles\W3SVC1"

# Active Sync Output folder, This is a temp location and will be delete after the script runs
$ActiveSyncOutputFolder = "C:\EASReports"

# Hit Threshold value where the report will notify the admin
[int]$maxhits = 1000

# Enable Email report, $true of $false
$SendEmailReport = $true

# Recipient
$recipient = "user@domain.com"

# Sender
$sender = "sender@domain.com"

# SMTP Server address
$SMTPServer = "192.168.1.1"

As you can see this script has the option to email the report but if this is set to $False then the EASyncOutputReport.html report will be placed in the folder $ActiveSyncOutputFolder path. Also this script will require you to run Set-ExecutionPolicy RemoteSigned

Script Requirements:
* Exchange 2010
* IIS Logs to use W3C
* IIS Logs schedule to be Daily

Example of the HTML output

Overview Report 09/12/2011 14:27:32

Detailed Report 09/12/2011 14:27:32

*** There will be a version 2! I have noticed that on large IIS logs it takes some time. I have found a far better/faster way gather this data

ActiveSyncHitsReport.ps1

I recently ran into a problem when trying to run New-DatabaseAvailabilityGroup commandlet. Each time I ran this command I got CreateCluster() failed with 0x57. Error: The parameter is incorrect. After serveral hours of re-creating the DAG objects I noticed something out of the ordinary. When you run the command it creates the DAG object in AD under the servers container. if you look at the ACL list you might notice that there are several Unknown Account SID’s. It appears that Cluster API is trying to validate all the Account SIDs. in my case there was about 200+. To work around this issue I did the following

1. On the Dag Node I ran this: cluster node /forcecleanup
1. This will cleanup the failed DAG setup
2. Then you delete the DAG computer object from AD that New-DatabaseAvailabilityGroup created
3. Then Pre Stage the DAG computer object
   1. https://technet.microsoft.com/en-us/library/ff367878.aspx
4. Check the ACL on the object and if there are any unknown SID’s remove them
5. re-run New-DatabaseAvailabilityGroup command

stumbled upon an interesting

Cannot open meeting item “FW: Test”. Cannot open the free/busy information. You do not have sufficient permissions to perform this operation on this object. See the folder contact or your system administrator.

Before I tell you how to fix the problem, I need to give some background on the exchange configuration.  Firstly I have created a new resource room in ECP and selected that another user in my organization to handle the booking requests.

Now we have a room that is has delegate that needs to accept or decline meetings for this room. Naturally our next test is to try and schedule a meeting. This can be done in OWA or Outlook it doesn’t matter.

I have booked the meeting and in OWA I see that the Resource Booking agent is waiting for approval.

When you log into OWA as your delegate you will see that everything is fine. There are no errors.

In Outlook 2007 and Outlook 2010 you are not able to view the email in the preview pane, instead you get an error. You can however accept the meeting by right clicking on the item.

What's happening here is that the way we add delegates to mailboxes in Outlook versus the way we do in ECP/EMC/EMS is different. Typically Outlook will dirty the delegates mailbox if there has never been anything created in there calendar. This error will only happen if it is the FIRST meeting to be accepted in the mailbox because in the preview pane it is trying to view the non-existent free busy data and build a view. This error is not present in OWA because in the preview pane doesn’t request to pull free busy data it simply gives you a text description of the meeting (note the 3rd screen shot).

Upon the creation of the Resource Room it does not dirty the mailbox for us so this is expected behavior. All the delegate needs to do is dirty the mailbox by doing 1 of the following.

1. In Outlook go to your calendar open the resource room calendar
2. Accept a meeting in OWA, or Right click on the meeting in Outlook and accept it

After that you can return to outlook and look at the meeting and it will show the Free busy information now.

I hope this helps anyone that might run into this!

The only fix is to request the vendor that issued you the .CRT file to export it again as .CER or .PFX

If you remove edge subscription any send connectors that have those servers listed as a source servers will be removed without warning. When this happens you could potentially cause NDRs to external recipients especially if this send connector was the only route out to the internet.

Workaround:

A workaround that would be viable is to create another send connector that uses the HUB server as a source server and then delete the edge subscription.