Virtuality

Most networks using Exchange connect with IMAP/SMTP next to MAPI access. When you are using SMTP it is very easy to send e-mail from a different e-mail address as the addresses you use on the server. Also when using a smartphone to check several mailboxes, like I do, you will want to send e-mail using several e-mail addresses in a secure way from all around the world.

So what I wanted to do was create a Receive Connector for relaying my e-mails for several e-mail domains.

For myself I am running Windows 2008 Small Business Server and it comes with three receive connector.

• Windows SBS Fax Sharepoint Receive SERVER; for localhost processes.
• Windows SBS Internet Receive SERVER; for receiving e-mail from other e-mail servers for your local users.
• Windows SBS Internet Relay SERVER; for relaying

So naturally I focussed on the third one. In my case this one is running at port 587, as not to interfere with the Internet Receive connector. Also I enabled the following Authentication protocols

• Transport Layer Security (TLS)
• Basic authentication, with Offer Basic authentication only after starting TLS

As the permission group I only checked Exchange Users, as this is a service for my local users.

After configuring these settings I tested this and of course it didn’t work. So I enabled protocol logging on the connector and tested it again. Now I got the following logging:

….
334 <authentication response>
SMTPSubmit SMTPAcceptAnyRecipient BypassAntiSpam AcceptRoutingHeaders,Set Session Permissions
<username>,authenticated
235 2.7.0 Authentication successful,
RSET,
250 2.0.0 Resetting,
MAIL FROM:<e-mail address>,
receiving message
550 5.7.1 Client does not have permissions to send as this sender

When I searched for a solution I came across lots of people with the same problem.

Two solutions where presented in the several discussions:

1. Add ms-Exch-SMTP-Accept-Authoritative-Domain-Sender right to NT AUTHORITY\Authenticated Users
   In the Exchange Management Shell type the following:
   Get-ReceiveConnector -Identity “Windows SBS Internet Relay SERVER” | Add-ADPermission -User “NT AUTHORITY\Authenticated Users” -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
2. Add NT AUTHORITY\SELF in the list of Send As permissions on the user account that experiences this problem.
   This can be done through the GUI or you can type the following in the Exchange Management Shell:
   Add-MailboxPermission -Identity <user alias> -User “NT AUTHORITY\SELF” -AccessRights SendAs

I tried both solutions and the problem remained the same. When I tried testing with an account in the Domain Admin group it worked, so it had to be a permissions issue on the receive connector.

I opened ADSIEdit and connected to the Configuration. Then I browsed to the receive connector, which you can find under:

Configuration -> Services -> Microsoft Exchange -> [my Exchange organisation] -> Administrative Groups -> [my Exchange group] -> Servers -> [my server] -> Protocols -> SMTP Receive Connectors

When we right click the receive connector and choose Properties, on the Security tab you will find all the security permissions.

This gave me the option to browse through the possible permissions to give to a user. I came across the ms-Exch-SMTP-Accept-Any-Sender and noticed that because it concerns the relay connector the permission ms-Exch-SMTP-Accept-Any-Recipient was already added for ‘NT AUTHORITY\Authenticated Users’ which makes sense.

So I added the ms-Exch-SMTP-Accept-Any-Sender to the permissions of ‘NT AUTHORITY\Authenticated Users’ and everything started working.

When you are reading the protocol logging which is being created, you will notice that it displays to the authenticated user the different permissions you added for the user. You can use this to check if all the required permissions are there.

When you read the logging included earlier in the post you will see that my server advertised the following:

SMTPSubmit SMTPAcceptAnyRecipient BypassAntiSpam AcceptRoutingHeaders

After making the three changes discussed in this post it looks like this:

SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam AcceptRoutingHeaders

So the two new permissions are shown here like they should be. Check this to make sure that adding the permissions went successfully.

Now i can finally send that e-mail that has been in the Outbox of my phone all evening

With the release of Exchange 2007 SP2 a lot of system administrators where hoping that Microsoft would include support for Windows 2008 R2.
However, although it was in the original planning for some time they decided to drop support in favor of Exchange 2010 which will of course fully support Windows 2008 R2.

On the Microsoft Exchange Team Blog we can read the reasons for this decision.

However during the installation of all the servers for a new organisation we wanted to try to use Windows 2008 R2 for everything. So although Exchange 2007 SP2 will never fully use all the new features of Windows 2008 R2, as Microsoft tells us, we wanted to see if it would be possible to at least run it

And this turned out to be relatively easy to do. Windows 2008 R2 includes a very nice feature called Program Compatibility.
When we right click on the setup.exe of the Exchange 2007 SP1 installation DVD and choose Troubleshoot compatibility we can do the following:

• Check ‘The program worked in earlier versions of Windows but won’t install or run now’
• Check ‘The program requires additional permissions’

Now click Next, choose Windows 2008 (Service Pack 1) and click Next. We then see the following screen:

When you click ‘Start the program’ the Setup process will start, the system readiness checks will succeed and the installation was succesful on our servers. Afterwards we repeat this process for the installation of Exchange 2007 SP2 but this is still some work in progress. This failes on the Mailbox Role with error “An error occurred. The error code was 3221684346. The message was: The data area passed to a system call is too small”. This same error is seen when we run the SP1 install without the Program Compatibility tool, but with SP2 this no longer seems to fix the error. We have succesfully updated the Client Access and Hub Transport role to SP2.

We also used this method for installing the Management Tools for Exchange 2007 SP2 on the Windows 2008 R2 Remote Desktop Session Hosts (as the Terminal Servers are called in R2).
For the forestprep and domainprep actions of Exchange 2007 SP1 we also need the Program Compatibility settings on the Windows 2008 R2 domain controllers. Exchange 2007 SP2 fully supports Windows 2008 R2 domain controllers.

This setup has been running for some time now and shows no problems.

Recently I conducted a migration from SBS 2003 to SBS 2008. During the migration of the Windows Vista laptops to the new environment some users experienced problems opening documents from the network drives with Office 2007.

The Office application opened in the normal start time, but then the application waited for 15 to 30 seconds before downloading and opening the document from the network drive. Having opened the document everything worked normally until for instance the user used the Open or Save menu. The application then started waiting again for some time.

Opening a document with Notepad showed normal loading times and experimenting with the file sizes didn’t make a difference.

This problem kept us busy for some time and searching with Google didn’t give a solution. Eventually we found the article Slow Opening of Office 2007 Documents From a Network Drive where the author gives the solution. This article describes the exact same problem and shows that the problem lies in the method of mapping the network drives in combination with the use of DFS, Distributed File System.

When mapping the network drives a choice can be made whether to use the FQDN (for instance \\domain.local\Dfs\Share) or the NetBIOS name (for instance \\DOMAIN\Dfs\Share).

The article describes that changing the mapping of the network drives from NetBIOS to FQDN solved the problem. In our environment the drives where already mapped using the FQDN so we tried reversing the solution. We changed the mapping to NetBIOS instead of using the FQDN and our problems were solved.

The opening of documents shows normal response times now. The remaining slow response for some users turned out to be caused by installed network printers which didn’t respond well at the time of testing. The timeout on connecting to the network printers causes some remaining slow response from Office, but fixing the response of the printers finally solved this as well and we could close the migration project.

With Windows Server 2008 R2 Microsoft introduces new functionality in Failover Clustering, Cluster Shared Volumes, which provides simultaneous access to cluster disks to multiple clusternodes.

A standard cluster disk in Failover Clustering can be changes into a Cluster Shared Volume. Failover Clustering will then appoint a Coordinator role for each disk and assigns this role to the clusternode that at that time owns the disk. This coordinator is responsible for managing the I/O access to the disk.

Continue Reading »

Tags: Clustering, Windows