With Azure AD Replication, you may notice that you have the following error when you take a look at your connector status;
Error: permission-issue Connected data source error code: 8344 Connected data source error: Insufficient access rights to perform this operation.
Solution: Error Code 8344
Firstly ensure that the user you are running AAD sync under, has the following permissions on the ‘root’ of your local AD domain.
Replicating Directory Changes: Allow
Replicating Directory Changes All: Allow
If the problem persists it’s usually because the account that is running the AAD sync does not have the appropriate rights to the mS-DS-ConsitencyGuid attribute for the affected users in the local Active Directory. The following commands will add the appropriate rights you ALL your local users;
Lastly, if you have this problem on some ‘sporadic’ users, check to ensure that their individual user objects and inheritance enabled on their user object, before retrying.
If the problem persists use the AD Connect Troubleshooter.
Fix Error Code 8344 with AD Connect Troubleshooter
Open Azure AD Connect > Configure.
Troubleshoot > Next > Troubleshooting > Launch.
Option 4 > Note: At this point you may or may not be asked to install the RTSAT tools, if so enter Y {Enter} > Option 12 > Y {Enter} > E {Enter} > Type in the name of the connector (in the example below that’s pnl.com).
You will be prompted to authenticate with an administrative account > You will then have to accept each change, by typing A {Enter} You will need to do this SEVEN TIMES.
When complete force a full initial replication.
[box]
Start-ADSyncCycle -PolicyType Initial
[/box]
At this point go an have a cup of coffee, then come back and check Synchronisation Service Manager. You should now be error free.
Related Articles, References, Credits, or External Links
I’ve seen this a few times now, I’ve had users that will not sync from Active Directory to Azure Active Directory (Office 365). When you look to see why, you will see something like;
The Connector {Your-Domain}.onmicrosoft.com – AAD contains another object with the same DN which is already connected to the MV.
Note: For the uninitiated, DN is Distinguished Name, and MV is MetaVerse.
If you attempt to troubleshoot the sync, you may also see something like this;
Object {Distinguished-Name} is not found in AAD Connector Space.
Solution
First we need to temporarily halt the sync;
[box]
Set-ADSyncScheduler -SyncCycleEnabled $False
[/box]
Then launch Sycronization Service Manager > Connectors > Select your AAD Connector > Delete > Delete connector space only > Yes.
Note: Whoa! it says I’m going to lose data, what are we doing?
Well we are essentially removing all the ‘cached objects associated with this connector, I think about it like ‘flushing the cache’. I’ve never seen this operation break anything, and I’ve certainly never ‘lost’ anything.
While it’s still running, do the same with your local AD connector.
Start the sync scheduler again.
[box]
Set-ADSyncScheduler -SyncCycleEnabled $True
[/box]
Perform a Full Import on your AAD connector..
With the above still running you can repeat a Full Import on your AD Connector
Providing the full import has finished (i.e the connector says ‘idle’) perform an Export on the AAD Connector.
Providing the full import has finished (i.e, the connector says ‘idle’) perform an Export on the Local AD Connector.
Background: Just introduced Exchange 2016 into Exchange 2013 Environment. Mailboxes on Exchange 2016, can send external mail and internal (to Exchange 2013) mail. No mail flows from Exchange 2013 to Exchange 2016. External mail to Exchange 2016, (which flows thought the 2013 server,) also fails.
Event ID 5006
Cannot find information about owning Mailbox Server {server-path} for database {database-path} in routing tables with timestamp {time-stamp}. Recipients will not be routed to this database.
Event ID 5015
Microsoft Exchange cannot find a route to the source transport server or home MTA server {server-path} for connector {connector-path} in routing tables with timestamp {time-stamp}. Microsoft Exchange is ignoring the source transport server.
Solution
Oh I struggled with this for hours! I removed and recreated the receive connectors, on the Exchange 2016 Server. I went though ADSIEdit and checked all the databases, servers and connectors had inheritable permissions, and that the Exchange Server group had the right permissions. I restarted the transport services, and rebooted the Exchange 2016 server.
I was about 7 pages deep in Google translating Spanish and Russian tech posts, when I started to think I might have to ring Microsoft. When I stumbled on a Technet post that had the same Event IDs I posted above.
ANNOYINGLY: The fix is to reboot the 2013 Exchange server! (So I had to plan in some downtime). I was a bit skeptical this would work, and it did take a few minutes, I watched the ‘Undeliverable Queue’ change and the mail get delivered.
Thank you EngineerBoy wherever you are!
Related Articles, References, Credits, or External Links
While testing mail flow on a new SBS 2011 Server, outbound mail worked fine, but no mail would flow in. When I attempted to Telnet in from a remote host this was what I saw;
421 4.3.2 Service not available
Connection to host lost.
Solution
Normally I’d expect to see an error like this if the Exchange ‘Receive Connector’ was misconfigured, (if you’re not using SBS 2011 create a new default receive connector and make sure there are no firewalls in the way).
If you are using SBS 2011 you need to run the ‘Connect to the Internet’ Wizard (seriously!)
After this check inbound mail flow again.
Related Articles, References, Credits, or External Links
To complete a migration from Exchange 2010 (or 2007) to Exchange 2016/2013, you need to introduce Exchange 2016 into your existing Exchange environment, then migrate your content onto the new server(s), and finally remove Exchange 2010.
Solution
Assumptions:
In this example I’ve got an existing Exchange 2010 environment running on Windows Server 2008 R2. I’m putting in Exchange 2016 onto a new server running Server 2012. Post install the NEW server will hold client access, and mailbox roles.
Exchange 2013/2016 Role Placement
Unlike with previous versions of Exchange, the 2016/2013 approach is NOT to split up roles to different servers, it’s considered good practice to deploy all roles on all Exchange servers.
Exchange 2013/2016 Licensing
Unless you have Microsoft “Software Assurance” you cannot simply upgrade to Exchange 2016 for free. You will need to buy the Exchange 2016 Base product. You may wish to look at an “Open Value Agreement”, which lets you pay the cost over a three year term.
The Exchange 2016 (on-premises) software itself comes in two flavours, Standard and Enterprise.
Standard: For small Exchange deployments (1-5 Mailbox Databases) and for non mailbox role servers in larger Exchange deployments.
Enterprise: For large Exchange deployments (1-50 Mailbox Databases).
Exchange 2013/2016 Client Access Licenses
As before there are two types of CAL for Exchange 2016 access. These are also ‘confusingly’ called Standard and Enterprise.
Note: An Enterprise CAL is NOT just for Exchange Enterprise 2016 and a Standard CAL is NOT just for Exchange Standard, this is a common mistake. Though you can mix and match, i.e. a standard CAL is required for all mailbox users or devices, adding an Enterprise CAL is only required for those existing users or devices requiring additional functionality.
Standard CAL: Required for all users (or devices) that require access to an Exchange mailbox. For most people these will be the CALS you need to purchase.
Enterprise CAL: Is an additional license that’s added to the Standard license, this enables the user to use archiving/journaling and unified messaging (Requires Outlook 2013). It also gives access to more advanced ActiveSync management policies and custom retention policies.
Exchange 2016/2013 Migration Step 1 “Planning / Pre Site Visit”
1. Media and Licenses: Before you start you will need to have the Exchange 2016 or 2013 CU2 (CU1 = Minimum) version of the install media (.iso or DVD). DO NOT attempt to perform the migration with a version of Exchange 2013 media that IS NOT at least CU1. Warning, this will be a DVD image (over 3.5 GB), you may wish to get this downloaded from a site with a decent Internet connection!
2. Make sure any third party Exchange software you are currently running is also supported on Exchange 2016, e.g. Anti Virus, Backup Solutions, Archiving, Mail Management, Mobile Device Software, etc, check with the software vendor.
3. DO NOT CONSIDER migrating anything until you know you have a good backup of your current Exchange environment. If you are lucky enough to have VMware ESX, Hyper-V or another virtualisation platform, consider doing a P2V conversion on your Exchange 2010 server then simply turning the 2010 Server off, then if it all goes to hell in a hand cart simply turn the original server back on again.
4. Outlook Client Access: Be aware your clients need to be using the following versions of Outlook BEFORE you migrate them.
I would suggest you run through the Microsoft Exchange Server Deployment Assistant, as a “Belt and braces” approach to the migration”
1. Before you do anything, it’s time for a common sense check, make sure your existing Exchange 2010 Organisation is happy and running cleanly, and has good communication with both the domain and your DNS. Get in the event logs and make sure it’s a happy server.
Time spent on reconnaissance is seldom wasted!
2. Run a full Windows update on your existing Exchange server(s), this will install any Exchange roll-ups that are outstanding.
3. If you are planning to utilise DAG, then you should install the following hot-fix on your Exchange 2010 servers before deploying SP3.
4. For coexistence of Exchange 2010 and Exchange 2016/2013, Your Exchange 2010 Servers must have Service pack 3 installed. If you are upgrading from service pack 1 you may see the following error.
1. The server that will run Exchange 2016, will need to be a domain member*, and I would run all the current updates before you start.
Once that is complete there are a number of server roles that will need adding. (Note: in Exchange 2013 these roles are the SAME for both CAS and Mailbox Servers, in 2016 there is only mailbox and edge servers anyway).
*Note: As with previous versions of Exchange it is recommended that you DO NOT run Exchange 2016 on a domain controller.
To add the Exchange 2013/2016 Server roles via PowerShell
Note: Here on my ‘Test Network’ the server in question is also a domain controller. In your production environment this will probably NOT be the case. If so, you will need to install the Remote Server Administration Tools for Active Directory.
6. I tend to disable feedback, but the choice is yours > Next.
7. Select the server roles that you wish to install.
8. Select the folder that you wish to install the Exchange program into.
Note: Remember if deploying multiple Exchange 2013/2016 servers, it’s considered good practice to keep the folder paths contiguous across all the servers.
9. If you plan to deploy third party malware protection (post Install), then you might wish to disable this, but in most cases you will want it enabled > Next.
Note: This is built on technology that was called ‘Forefront’ in previous versions of Exchange.
10. Pre deployment readiness checks will be carried out > when complete > Next.
11. Setup will take quite some time.
12. When complete, tick the box to launch the admin console > Finish.
13. After a few seconds the Exchange Admin Center will open.
Note: If you log in and get a blank screen, ensure your users has ‘inheritable permissions’ enabled, (on the security tab of their user object in AD)
14. At this point I would move the new Exchange Database from its default location to its own volume/folder, (again keep this path contiguous across all the new servers). The following PowerShell command will do this for you;
STOP! Before you proceed you need to think about OWA access. For internal access this will not be a problem BUT if you have users that access OWA externally (e.g. via https://mail.yourpublicdomain.com/owa) Then you will have to DO SOME PLANNING. Unless you have two free public IP addresses, your router/firewall can only point to one CAS server at a time.
STOP AGAIN! OK I’ve had more than one email about this so, here’s a warning. Moving Mailboxes creates logs, the more you move, the more logs it creates. The only way to clear these logs properly is to do an Exchange Aware/VSS Level backup. If you just start moving mailboxes without keeping an eye on this you can fill up a volume with logs, and if you are daft enough to have this on our system volume you can take the server down, you have been warned! OrSee the following Article
1. First make sure that the new server can see the existing Exchange infrastructure. From within the Exchange Admin Center > Servers. You should see both your Exchange 2010 Servers and the new Exchange 2016 Server.
Note: You can see the same with the following PowerShell command;
[box]Get-ExchangeServer | select Name, ServerRole, AdminDisplayVersion | ft –auto[/box]
2. Test move one mailbox from Exchange 2010 to 2016, Recipients > Mailboxes > Locate our Test User > Move Mailbox.
3. Give the test migration a name, and browse to the new datastore (Note: If the move fails you can increase both the BadItem limit and the LargeItem limit here as well) > Next.
4. New.
5. You will be asked if you want to the ‘Migration Dashboard’.
6. Here you can watch progress (remember to keep hitting ‘refresh’).
7. If you prefer to use PowerShell you can migrate all mailboxes from one database to another with the following command;
Depending on the amount of mailboxes this can take a while!
8. Then test mail flow to/from this mailbox to internal recipients in the Exchange 2010 infrastructure, and then test mail flow to/from an external mailbox.
Note: At this point you might struggle to connect to the Exchange 2016 Admin Center as ‘Administrator’, because that user’s mailbox is still on the Exchange 2010 Server. If that happens to you and you are ‘Locked Out‘ of the Exchange Admin Center, simply add the user you migrated already, to the Exchange Organization Management group, and log in as that user to https://{Exchange-2016-Server-Name}/ecp
9. You can now migrate the remainder of your mailboxes.
Note: Depending on mailbox size this can take a VERY LONG time, I would suggest staging this migration gradually. To view progress;
Exchange 2013/2016 Migration Step 6 “Change Mail flow”
At this point you need to change the SMTP feed from the old Exchange 2010 box to the new Exchange 2016 Server, how you do this depends on your network setup, some examples of how you might do this are,
i. Change the SMTP (TCP Port 25) Port redirect on your router/firewall.
ii. Swap IP addresses from the old to the new server.
iii. Change the translation from public to private IP address to point to the new IP.
Note: If you have any mail scanning servers, anti spam hardware devices etc, then they will also need changing to point to the new server.
1. You will need to add the new server to your Exchange ‘Send Connector’ and remove the Exchange 2010 Server. (Note: I’m assuming you only have one send connector, if you have more than one i.e. for particular domains, or for secure TLS mail you will need to do these as well). From Exchange Admin Center > Mail flow > Send connectors > Select the send connector > Edit > Scoping > Add the 2016 server > Remove the 2010 server > Save.
2. You will not need to create receive connectors on the Exchange 2016 Server, if you navigate to mail flow > receive connectors > Change the drop down to point to the Exchange 2013 Server. You will see there is a ‘Default Frontend’ Connector already configured for Exchange 2016.
3. At this point, it would be sensible to once again check mail flow, to and from an external mail account.
Related Articles, References, Credits, or External Links
Thanks to Simcha Kope for the feedback (Adding RSAT-ADDS)
Thanks to Austin Weber for spotting my PowerShell typo.
Thanks to Tony Blunt for the log file PowerShell syntax omission.
Microsoft Exchange could not find a certificate that contains the domain name {name.domain.com} in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector SendConnector with a FQDN parameter of {name.domain.com}. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
In the error massage take note of {name.domain.com} this name is being used on one of your mail connectors, and the certificate on the Exchange server has a different name.
Solution
1. Launch Exchange Management Console > Organization Configuration > Hub Transport > Send Connectors > Right click your Send connector > Properties > Make sure the “Specify the FQDN this connector will provide…” section is the same as the name on your servers certificate.
2. Launch Exchange Management Console > Server Configuration > Hub Transport > Receive Connectors > Right click your Send connector > Properties > Make sure the “Specify the FQDN this connector will provide…” section is the same as the name on your servers certificate.
3. Start > run > services.msc {enter} > Restart the Microsoft Exchange Active Directory Topology Service > Select “Yes” to restart the other services.
Related Articles, References, Credits, or External Links
You have an x64 Bit server (x32 is not supported for production). You have an x64 Bit copy of Server 2008 or Server 2008 R2.
Solution
Pre site visit
To save time onsite it may be worth (If remote connection is available) downloading the relevant install media and service packs beforehand.
Pre requisites
1. .net 2.0 – pre installed in Server 2008 and Server 2008 R2
2. MMC 3.0 – pre installed in Server 2008 and Server2008 R2
3. Powershell needs to be installed, its pre installed on Server 2008 R2, on Server 2008 do the following > Start > run > cmd {Enter}> enter the following command,
[box]ServerManagerCmd -i PowerShell[/box]
Note: It may look like it’s hung but after a while it will say “Success: Installation succeeded.”
4. You now need to add a server role > Start > Server Manager > Roles > Add Roles > IIS (Web Server) > Start > Server Manager > Roles > Add Roles > Next > Tick “Web Server IIS” > Next.
5. Security Section > Add Basic Authentication, Digest Authentication, and Windows Authentication.
8. Now Select Features > Ad Features > Expand Remote server Administration Tools > Expand Role Administration Tools > tick AD DS and AD LDS Tools > Add Required Features > Next > Install > Close > Reboot when promoted.
9. Run Windows update.
Pre Install Tasks
Assuming you’re installing from CD/DVD (if not change E: to the correct path.)
If you are going to do the via RDP you MUST! Be on the console session.
1. From command line Execute the following command,
I have on one occasion needed to copy all the DVD/CD’s contents to the server for Installation to be successful.
1. Assuming the CD/DVD from which you are deploying Exchange 2007 from is E: > Start > Run > CMD {enter}.
2. Execute the following command,
[box]E:Setup.exe[/box]
3. Click Step 4 > Introduction Screen > Next > Tick “I accept the terms….” > Next > Next > Select Typical > Next.
4. You will then be asked if you have and Outlook 2003 or earlier clients Answer Yes or No > Next.
5. Exchange 2007 will now do some checks > Click Install > When done > Finish >Reboot the server.
6. Launch the Exchange Management Console > Ignore any Licence warnings.
7. Select Server configuration > Select the new Server > Action > Enter Product Key > Type in your Key > Read the Warning > Finish > either reboot or restart the “Microsoft Exchange Information Store” service.
8. At time of writing SP2 is not supported on R2. But run Windows update to get any further updates/roll ups.
Error: This compuer is running Windows Server R2 Enterprise. Exchange Server 2007 is not supported on this operating system.
9. The new 2007 Organisation will have one mailbox database and one Public folder database (If you said “Yes” I have Outlook 2003 or earlier during install) > Expand Microsoft Exchange > Server configuration > Mailbox > Select the server > The Databases will be displayed in the center panel at the bottom.
10. You can select the databases > Right Click > “Move Database Path” to move them onto another partition.
11. Point SMTP Feed to the New Server, the MX Record should now be pointing to the public IP of the new server OR the Firewall SMTP Port re-directs needs changing to the new server.
12. Once the SMTP Feed has swapped across, inbound mail may fail and return the following error,
mail.domainc.com #530 5.7.1 Client was not authenticated ##
To fix that you will need to allow anonymous access on the servers default receive connector. > Launch Exchange Management Console > Server Configuration > Hub Transport > right click the “Default {server name}” connector > Permission groups > tick “Anonymous users” > Apply >OK.
5. You may also find outbound mail will fail, and sit on the outbound queue with the following error,
A matching connector cannot be found to route the external recipient
To fix that you will need to create a “Send Connector”. Launch the Exchange 2007 Management Console > Organization Configuration > Hub Transport > Send Connectors > New Send Connector > Give it a name and CHANGE the intended use from Custom to Internet > Next > Add > In the address box type a single asterisk * > tick Include all subfolders > OK > Next > Add a smart host IF you use one > Next > Next > New > Finish.
Install Antispam Agents
1. Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell.
2. Execute the following commands,
[box]
cd "c:Program FilesMicrosoftExchange ServerScripts"
./install-AntispamAgents.ps1
Net stop "Microsoft Exchange Transport"
Net start "Microsoft Exchange Transport"
[/box]
3. Stop and restart the Exchange Management Console (NOT the exchange Management Shell).
Note: If the antispam Agents are installed remove the following folder from the backup (Or it will error).
Microsoft have not only slipstreamed the service pack into the install media, they have (Finally!) got the install routine to put in all the usual pre-requisites, roles, and features, that you had to do yourself before. (With the exception of the Microsoft 2010 filter pack, but even then you can do that after the install).
The procedure below was done on a single server in a test environment, to demonstrate the simplified procedure, it IS NOT good practice to install Exchange (any version) on a domain controller.
Solution
Before Site Visit
1. Have your install media downloaded and ready to go (Make sure you also have the unlock codes for Exchange – or you will have 119 days to licence it, post install).
2. Does your current anti virus solution support Exchange 2010? Do you need an upgrade?
3. Does your current backup software support Exchange 2010? Do you need to purchase extra remote agents or updates?
Before Deploying Exchange 2010
1. Depending on what documentation you read, some say that the global catalog server(s) in the current site need to be at least Server 2003 SP2. Other documentation says the schema master needs to be at least Server 2003 SP2. Let’s hedge our bets, and make sure that ALL the domain controllers are at least Server 2003 SP2 🙂
2. Your domain and forest functional levels need to be at Windows Server 2003.
3. Don’t forget – your server needs to be x64 bit (the video below was shot on a Server 2008 R2 server).
4. Make sure both the server you are installing on, and the Windows domain, are happy (get into the event viewers of your servers and have a good spring clean before deploying Exchange 2010).
6. Install the roles required with the following PowerShell Commands;
[box]
Import-Module ServerManager
For Client Access, Hub Transport, and the Mailbox roles issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Web-WMI -Restart
For Client Access and Hub Transport server roles issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Web-WMI -Restart
For only the Mailbox role issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart
For only the Unified Messaging role issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience -Restart
For only the Edge Transport role issue the following command;
Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart
[/box]
7. Set the Net.Tcp Port Sharing Service for Automatic startup by running the following command;
While putting in a New Exchange 2010 server today, I test moved a mailbox to this new site, and could not get mail to flow to the Exchange 2010 server at the clients main site.
451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host , but that did not succeed. Either there are no alternative hosts, or delivery failed to all alternative hosts.
Mail flowed from the main site to this new site, and internal mail at the new site was fine, but any mail destined for the main site, or going external (because the main site has the only server that can use the Exchange organization send connector) would fail with this error.
Solution
I did a lot of trawling to try and find the answer to this, and discovered lots of reasons for this to happen, so rather than just posting what fixed mine, from the most popular to the most obscure try these in order, and attempt to send mail after each step.
Note: Any change on an Exchange Server’s Receive Connectors should be followed by you restarting the Microsoft Exchange Transport Service (on the server you made the change on) before you try again.
1. On the server you are trying to send TO, check the properties of the Default receive connector and ensure ‘Exchange Server authentication’ is selected.
2. On the server you are trying to send TO, If you have a connector configured to ‘relay’ mail, make sure that the server(s) or network specified DOES NOT include the IP address of the server you cannot send FROM. Also Make sure on the authentication tab ‘Exchange Server authentication’ is NOT selected.
3. If you have Cisco PIX Firewalls between these two mail servers (running version 6 or earlier) make sure smtp fixup is disabled.
[box]
Petes-PIX>
Petes-PIX> enable
Password: *******
Petes-PIX# configure terminal
Petes-PIX(config)# no fixup protocol smtp 25
Petes-PIX(config)# write mem
Building configuration...
Cryptochecksum: f59a9bd3 3129b8bc 474b2415 52f2db0f
1049 bytes copied in 0.430 secs
[OK]
[/box]
4. If you have Cisco ASA Firewalls between these two mail servers, then remove esmtp from the default inspection map.
At this point I admitted defeat and picked up the phone and called Microsoft. One of their support engineers looked at the connectors and settings, and tested the DNS, had me create a new connector, still mail refused to flow. He did however get me pointed in the right direction. When attempting to Telnet to the Exchange server on the main site this is what we saw;
This is what we should be seeing;
Eureka!
I put all the firewalls in, so I know how they are configured, and I know this client has a CSC module in the ASA 5510 at the mail site, I managed to get the output above by rebooting that module, as soon as it was back online we reverted to the short list again. Also while the CSC was rebooting all the mails stuck on the outbound queue cleared.
Enabling CSC Bypass for a Remote Mail Server
Note: Your class-maps, and access-lists may have different names but this should point you in the right direction.
1. Connect to the ASA, view the policy-maps in use.
[box]
Petes-ASA# show run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
inspect pptp
inspect ip-options
class global-class <<<<< Here we go
csc fail-open <<<< This is the one we are looking for
!
Petes-ASA#
[/box]
2. We can see the class-map the CSC is using is called ‘global-class’, let’s take look at that.
[box]
Petes-ASA# show run class-map global-class
!
class-map global-class
match access-list global_mpc <<<<Here's how its being applied
!
[/box]
3. Now we know that’s being applied with an access-list called global_mpc, let’s see what that’s doing.
[box]
Petes-ASA# show run access-list global_mpc
access-list global_mpc extended deny ip host 10.1.0.253 any
access-list global_mpc extended permit tcp any any object-group DM_INLINE_TCP_1
Petes-ASA#
[/box]
Note: Remember permit means inspect and deny means don’t inspect, you can see mine’s set not to scan the CSC update traffic because that’s good practice;
4. So I just need to add in the IP of the Exchange server I cannot send from to make its traffic bypass the CSC Module. Remember to put it at the top so it gets processed before the permit or it will get ignored.
[box]
Petes-ASA# configure terminal
Petes-ASA(config)# access-list global_mpc line 1 extended deny ip host 10.3.0.2 any
