I sometimes come across customers that would like to relay email through their Exchange Sever from external clients and maybe use a different sending address.  Here is how I configure this. First, we will create a new receive connector via the Exchange Powershell. To do so, open up the Exchange Management Shell (powershell) Once this loads, use the following command New-ReceiveConnector -Name ‘ExternalRelay’ -Usage ‘Client’ -RemoteIPRanges ’0.0.0.0-255.255.255.255′ -Server ‘SERVER’ Here is an example: Now we have created the Receive Connector, and you will see this in the Exchange Management Console. Let’s check our work, even though it was only one line of text Now we can verify the network, authentication, and permission groups settings to see how a Client receive connector has been configured. If you go to the properties, you will see that it’s listening on port 587 , that it has enabled Basic authentication over TLS, and that it is only allowing Exchange Users (Authenticated Users) to connect. You will see all of this by looking at the connector in the Exchange Management Console. NOTE: Make sure that port 587 is open in your firewall or this will not work for external users Further inspection of the AD permissions on the receive connector show that authenticated users have the ms-Exch-SMTP-Accept-Any-Recipient right. This is the correct relay permission and you should never have it be owned by anonymous users. You can view and verify this by running the following powershell command: Get-ADPermission “ExternalRelay” | where {$_.ExtendedRights -match “ms-Exch-SMTP-Accept-Any-Recipient”} | fl You will see the output looking like: If it says under user “NT AUTHORITYANONYMOUS” then you have an open relay. Stop and delete the connector! Next, we need to set some additional parameters to make this work. To allow the authenticated user to be able to send email with a different address, we will use the following powershell command   Get-ReceiveConnector ExternalRelay | add-ADPermission -User “NT AUTHORITYAuthenticated Users”-ExtendedRights “ms-Exch-SMTP-Accept-Any-sender” looking like: If you are running an SBS 2008 or SBS 2011 server, this also applies: If you have successfully run the Internet Address Management Wizard from the SBS Console, then your Exchange certificate for TLS has already been installed and configured. You can verify this by running the Get-ExchangeCertificate commandlet and find the certificate with your external DNS domain name. The certificate will have IPWS listed under Services, which stands for IMAP, POP, Web and SMTP respectively.   At this point, make sure that your Client receive connector is configured with the same FQDN that is listed in the subject of your Exchange certificate. This will be displayed in the banner: Once all of this is done, you are ready to setup Outlook, Outlook Express, Windows Mail, etc. Important points here are: The client machine must trust both the Exchange certificate and the Root CA in which it was created from. A good test is to open IE on the client and browse OWA to see if you get the certificate warning(s). You must configure the mail client to connect on port 587 and to send the proper credentials for authentication. The server requires a TLS connection, you must specify this in the mail client   Some of this information in this blog was obtained from the SBS Blog team at  http://blogs.technet.com/b/sbs/archive/2008/09/18/how-to-configure-trusted-smtp-relay-in-exchange-on-sbs-2008.aspx Lyle Epstein Kortek Solutions Lyle Epstein’s Systems Engineer Blog

Recently I was working on a client who is setup with a SBS 2008 server and workstations running Windows 7 Professional SP1. I noticed that when a particular user would login it would take upwards of 10 minutes for the welcome screen to go away and the desktop to be displayed. As part of the troubleshooting, I had the user login to a different workstation with their same credentials and we experienced the same slow login. when I looked at the event log, I saw the following error: Log Name:       Application Source:         Microsoft-Windows-Folder Redirection Date:           4/21/2012 10:57:42 PM Event ID:       502 Task Category: None Level:          Error Keywords:       User:           DOMAINfirstlast Computer:       DOMAIN-PC.DOMAIN.local Description: Failed to apply policy and redirect folder “Documents” to “SERVERRedirectedFoldersfirstlastMy Documents”. Redirection options=0×9021. The following error occurred: “Failed to copy files from “SERVERRedirectedFoldersfirstlastDocuments” to “SERVERRedirectedFoldersfirstlastMy Documents””. Error details: “The system call level is not correct. “. I did some research on this error, and came up with one valid result, which claimed that it was being caused by server quotas. As part of the trouble shooting, I turned off quota’s on the server, however I had previously checked the users properties in the SBS 2008 console and verified Folder Redirection was enabled, but the quota’s box was unchecked. I do question why the policy was attempting to take the same server and users folder and move files from the “Documents” folder to the “My Documents” folder. As I checked the GPO, it is set to move the files from the old location which is a default setting. So to take the troubleshooting a step further, I ran GPRESULT /V > C:gpresult.txt  and viewed this text file. I do not see anything out of the ordinary being applied to the computer. Now, when I check the GPO’s on server, I see a old GPO that was created and is no longer being applied. In that GPO, I see the following: As you can see from this screenshot, the disabled “Folder Redirection” GPO had the policy pointed to the SERVERRedirectedFolders%USERNAME%Documents but if we look at the Small Business Server Folder Redirection Policy which is created by the Small Business Server, it is pointed to SERVERRedirectedFolders%USERNAME%My Documents   as shown below On the Windows 7 machine, when I look at the properties of the “My Documents” folder, I see it is still pointed to the old policy’s setting, of SERVERRedirectedFolders%USERNAME%Documents as shown below: So how do we go about fixing this? Well, the best way to fix this is to edit the current GPO, Small Business Server Folder Redirection Policy. On this GPO, I changed the setting “Move the contents of Documents to the new location” to disabled by unchecking the box as shown below: Then, on the Windows 7 machine, at the command prompt type in GPUPDATE /FORCE and then logoff Now I login as that user, and look at the event log. We now see success, as the policy does not need to move the existing “Documents” to “My Documents” and the policy is able to successfully apply as shown below. Now there is one more step to fix this issue. I will need to copy the data from the “Documents” folder to the “My Documents” folder. When I attempted to look at the old Documents folder, it was now empty. The reason for this, Offline Files are enabled on the Windows 7 machine, and as it couldn’t connect to the previous path, all the time the user was saving documents it was offline as you can see in the previous picture of the properties of My Documents it was missing the green sync icon. So when I logged in to the computer with the fixed policy, the Windows Sync Center determined it was now online and able to write to SERVERRedirectedFoldersfirstlastMy Documents , and it has the data in the CSC cache, so it just copied the data back to the server for me. If you don’t have Offline Files enabled, simply copy the data from Documents to My Documents folder. Here is a screenshot showing it now online   If you are wondering why there are two My Documents folders, the second one that is not Sync’d is actually Documents. I just deleted this folder as it is not valid. I suggest re-enabling this policy setting once the issue is resolved so that if you have a user who didn’t have this policy applying or in the SBS Console you checked the box  and you now want it, that the files are moved from their default location to the server location. I also saw that Microsoft released a hotfix titled You encounter a long logon time after you enable the “Do not automatically make redirected folders available offline” Group Policy setting in Windows 7 or in Windows Server 2008 R2 at  http://support.microsoft.com/kb/2525332   however, in this case it does not apply. As you can see, the error The system call level is not correct is a very generic error which by just looking at it, tells you almost nothing. Lyle Epstein Kortek Solutions Lyle Epstein’s Systems Engineer Blog

Today my wife updated her Sprint Samsung Transform phone with the latest Android OS. I have been waiting for Sprint to push out this update as I found a very strange bug in the base OS that was shipped with the phone in November 2010. For a list of versions and when they were shipped, see http://socialcompare.com/en/comparison/android-versions-comparison The bug I identified was if you setup the phone to Sync with the Exchange server, in this case Exchange 2010 SP1 RU2 and then proceed to select a contact, change the picture of the contact to one that is on the device, and re-sync, you will now see the new picture in your Outlook. That is how it is suppose to work. The bug part comes in when you now edit that contact, say change the phone number or email address. Now sync the device, and you will notice the data doesn’t change in the device. The only way to fix it from my testing was to delete the contact via the phone. Once you do that, re-sync, and it will be gone from the Contacts in Outlook. Now go into your deleted items and you will see the contact. Move it back to your contacts, and re-sync the phone, and the contact is now correct on the phone. But if you make a change to the contact again, you will run into the same issue. This was VERY annoying! I had found an update to the Android OS but it required rooting the phone, something I didn’t want to do. After the update came down today from Sprint, I retried my issue, and the bug has now been fixed. Other things I noticed in the new update is the support for OOF, or Out of Office. That is a nice touch as Active Sync get’s more aligned to the features in Exchange 2010 and EAS. I also noticed that the new update now enforces Active Sync’s security policies, including requiring a device password. Now we wait for Microsoft’s own Windows Phone 7 to start supporting more Exchange EAS policies. If you are interested in knowing more about EAS, here is a chart by Marco Nielsen

Have you received this error? The SBSMonitoring database is nearing maximum size on SBS 2008. I was getting this on a SBS 2008 server running the SBS BPA. From the error message, it’s pretty clear that the SBSMonitoring database is too large to work normally. There is a fix for this and it turns out the same SQL script that is used for an SBS problem where the Console displays too slowly is part of the solution. To shrink the database, Please follow these steps: Step 1: Download the following file to the server you are going to be working on: 1. http://cid-d5fe25afb6c3615f.skydrive.live.com/self.aspx/.Public/updateSBSMonitoring.sql 2. I recommend you save the file to an easy to access path, such as c:windowstemp. Step 2: Complete a backup of the SBSMonitoring Databases 1.Open Services from Administrative Tools , Services 2.Accept the UAC prompt 3.Find and stop the SQL Server ( SBSMONITORING ) service. 4.Make a copy of the files in the following folder: 1.C:Program Files (x86)Microsoft SQL ServerMSSQL.1MSSQLData 5.Once the file backup is completed, start the SQL Server (SBSMONITORING) service. Step 3: Proceed to run the following set of commands to implement the improvements 1. Open an Administrative Command Prompt (Run As Admin) 2.Type the following command, substitute the path to the updateSBSMonitoring.sql file as needed (We recommend that you do NOT copy & paste this command directly from the blog post): 1. Sqlcmd -S %computername%SBSMonitoring -E