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

Today I was performing a migration from SBS 2003 to SBS 2011. I performed all the checks and ensured I had all the updates in place. During the migration the SBS 2011 server failed the migration. Upon further investigation I noticed that only 1 role transferred over from the old DC to the new one. On the old SBS 2003 server I saw: Upon doing some more research, I came across this hotfix from Microsoft http://support.microsoft.com/kb/981259 which does not specifically address Exception e0010004 but does address e0010005. I installed this hotfix and then proceeded to manually transfer all FSMO roles using NTDSUTIL on the SBS 2011 server from it’s self to it’s self . This might sound strange, but I wanted to do this per another article I read on Microsoft’s site. Once I confirmed that all the roles transferred over from the new SBS 2011 to it’s self. I then moved the roles back to the old SBS server. Then verifying event logs, everything looked clean and happy. I also noticed this event on the old SBS 2003 server. This seemed odd to me because look at the user….it is a a SID with no matching name. This is not normal. I then unpromoed the failed SBS 2011 server and removed it from the domain. I then decided to inspect the SBS 2003 DNS server. I noticed under GC’s that there were two entries. One was the current server, in this case 10.55.100.10 and another of 10.55.100.60. Well there was no other GC with an IP of this, so that stood out like a sore thumb. I then deleted this invalid entry and looked at all other entries, Name Servers, etc. to verify it was clean. On the old SBS 2003 server, I followed Microsoft troubleshooting to increase my logging. To increase NTDS diagnostic logging, change the following REG_DWORD values in the registry of the destination domain controller under the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostics Set the value of the following subkeys to 5: 5 Replication Events 9 Internal Processing Note Level 5 logging is extremely verbose and the values of both subkeys should be set back to the default of 0 after the problem is resolved. Filtering the Directory Services event log should be performed to isolate and identify these events. I did this on the source controller even though it mentions to do this on the destination server. Next I restarted netlogon service via command prompt. NET STOP NETLOGON & NET START NETLOGON I performed the migration again. It failed, but I was able to capture a lot more events in the event log. This time I saw Event ID 1925: Attempt to establish a replication link failed due to DNS lookup problem. Following  http://technet.microsoft.com/en-us/library/cc778061(WS.10).aspx   I started looking at DNS as the issue. this lead me to http://technet.microsoft.com/en-us/library/cc785014(WS.10).aspx It turns out, that someone previous had turned of Zone transfers. The DNS server looked like this: and this: To fix it, it should look like this: and Make sure to also check the AD domain, in this case csg.local, as those settings were also modified. I also noticed that they had DNS forwarders on, pointing to external address’s, but when I ran the original Internet Connection Wizard on the SBS 2003 server, it made no mention of this. Weird. Ah, once I did this, I was able to migrate correctly. Note, make sure to cleanup the old failed SBS 2011 servers from AD, Name servers and DNS so you get a clean migration. As this was a new customer for me, I had no knowledge of the previous IT person’s skills or abilities, or how things were setup or should I say not setup correctly. Lesson learned is when you enter a situation where you don’t know what was done before, look at everything, even though it is time consuming, the troubleshooting takes even more time. Lyle Epstein Kortek Solutions Lyle Epstein’s Systems Engineer Blog

Microsoft released an update this week for the Windows Server Solutions BPA that covers a number of products, including: Small Business Server 2011 Standard Edition Small Business Server 2011 Essentials Windows Storage Server 2008 R2 Essentials Windows MultiPoint Server 2011 More information about this update is available on the Official SBS Blog page at http://blogs.technet.com/b/sbs/archive/2011/09/29/windows-server-solutions-bpa-updated-september-2011.aspx So how do you get the update? First, make sure you have the Microsoft Baseline Configuration Analyzer 2.0 installed. To get it, go here . Next, make sure to download and install the Windows Server Solutions Best Practices Analyzer 1.0 here During the install, you will be prompted with this screen: Make sure to check this box during your install, or you will not be prompted to automatically update! Once you have it installed, launch the BPA either via the SBS Console under security (if you selected to integrate it in the console) or when you launch it under the start menu. You will see in the system tray an icon/pop up stating to update, like this: Select that, and a window will open Close the BPA you have open and then wait about 5-10 seconds. The next box will change and allow you to click on it. That’s it, you are now updated! Hey Lyle, I don’t see it prompting me. Why? Ok, so you got it installed, but now you launch it and don’t see it prompting you for the update. No problem, here is how to fix this: Open up the registry and navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsServerSolutionsBPA Look for the DWORD item “Update”.  It is probably set to a 0. We want to change it to a value of 1. It should now look like this:   Close out the BPA if you have it open. Now re-launch it and you will see it appear in the SysTray. 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

I began seeing this error on a migrated SBS 2011 Standard server in the event log Microsoft-Windows-Small Business Server/Operational section

Today I was troubleshooting a strange issue in the SBS 2011 Console. When I select Shared Folders from the SBS 2011 Console and click on Change Folder Permissions the SBS Console crashes with Windows SBS 2011 Standard Console has stopped working , as shown below

Today I did my first SBS 2003 to SBS 2011 Standard migration. I did all the checks, BPA’s, and every other best practice I have learned over the years including reading Susan’s blog at http://msmvps.com/blogs/bradley/archive/2010/12/23/sbs-2011-migration-keys-to-success.aspx . Everything on the source server looked great. I created my answer file, and started the migration installation. Everything seemed to go fine, until the final screen which said: I thought that was quite weird. Upon further digging, I noticed in the ExchangeSetupLogs folder the file ExchangeSetup.log had the following errors: [12/28/2010 00:35:18.0614] [1] Installing MSI package ‘C:Program FilesWindows Small Business ServerBinCMPNENTSEXCHANGE14_SP1exchangeserver.msi’. [12/28/2010 00:35:18.0616] [1] Installing a new product. Package: C:Program FilesWindows Small Business ServerBinCMPNENTSEXCHANGE14_SP1exchangeserver.msi. Property values: DISABLEERRORREPORTING=1 PRODUCTLANGUAGELCID=1033 DEFAULTLANGUAGENAME=ENU DEFAULTLANGUAGELCID=1033 INSTALLCOMMENT=”Installed language for this product: English (United States)” REBOOT=ReallySuppress TARGETDIR=”C:Program FilesMicrosoftExchange ServerV14″ ADDLOCAL=AdminTools,Bridgehead,ClientAccess,Mailbox,AdminToolsNonGateway [12/28/2010 00:35:46.0524] [1] [WARNING] Unexpected Error [12/28/2010 00:35:46.0524] [1] [WARNING] Installing product C:Program FilesWindows Small Business ServerBinCMPNENTSEXCHANGE14_SP1exchangeserver.msi failed. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance. Error code is 1601. Last error reported by the MSI package is ‘Error writing to file: amd64_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30729.4959_x-ww_db77817b.cat.