Exchange Admin Activities

After migrating distribution list from exchange 2003 to exchange 2010, Owner of the DL can't have permission to manage the DL First of all we should make sure that all the DL should be convert to Universal and upgraded to Exchange Server 2010 and then follow the below steps to resolve the issues. One question I got in response to my article “ Group owners cannot manage distribution groups once migrated from Exchange 2003 to 2010 ” was the steps required to tweak the default role assignment policy so that the owners can modify the groups, but users cannot create or delete distribution groups. Let me explain the steps required, which have to be done in the Shell. The permissions to create/modify/delete distribution groups are in the default role named “MyDistributionGroups”. Hence, all we need to do is to take away the role entries which gives users right to create and delete a distribution group (New & Remove-DistributionGroup cmdlets). But, we don’t want to mess with the

Converting and upgrading distribution groups When migrating to Exchange 2010 from Exchange 2003, you may be carrying over several mail-enabled non-universal groups. These groups will still function, but the administration of these objects within the Exchange tools will be limited. In addition, several distribution group features provided by Exchange 2010 will not be enabled for a group until it has been upgraded. This recipe covers the process of converting and upgrading these groups within the Exchange Management Shell. How to do it... To convert all of your non-universal distribution groups to universal, use the following one-liner: Get-DistributionGroup -ResultSize Unlimited ` -RecipientTypeDetails MailNonUniversalGroup | Set-Group -Universal Once all of your distribution groups have been converted to universal, you can upgrade them using the following command: Get-DistributionGroup -ResultSize Unlimited | Set-DistributionGroup -ForceUpgrade  

Daily Exchange Health Checklist   Here a few daily tasks that I perform each morning after a cup of coffee to ensure that my Exchange environment is running smoothly. This has proven very helpful in preventing many issues with my Exchange servers. I came up with the list while managing Exchange 2000/2003 environments but it still helps me with Exchange 2007 as well. Hope it will help others out there. Check event viewer for warnings/errors on all Exchange Servers Check for database fragmentation Check postmaster mailbox for NDRs Check exchange statistics Check bad mail folder for trends Check OS status on Exchange boxes Check if plenty of disk space is available on all BE & FE servers Check for cluster failover in cluster admin Check message load in the queue viewer Check OS/Exchange Services Check results of real-time performance monitoring for all servers Review event, performance vs. anti-virus logs Track message for security project Verify integrity of Exch

Installing, Configuring Exchange 2007 Edge Server (Part 2)   In Installing, Configuring Exchange 2007 Edge Server (Part 1) we started the installation of an Exchange 2007 Edge server at the DMZ. So far we installed the Exchange Edge role on a standalone Windows 2003 server. The server is still not connected to the rest of the Exchange organization running internally. Indeed we could employ Edge as the perimeter server even if we were not running Exchange internally. As is, Edge only requires port 25 communications and the configuration of send/receive connectors, to act as a relay to any SMTP server. However, quite obviously, Edge also includes special support for running together with an internal Exchange 2007 organization. This functionality is provided by the EdgeSync service. Running on an internal Hub transport server, EdgeSync pushes information to the Edge server. The following is some of the information transferred; more details are available from the article EdgeSync R

Installing, Configuring Exchange 2007 Edge Server (Part 1) Despite the success in conquering internal corporate networks, earlier Exchange versions failed to replicate the same success at the DMZ. One reason for this was the Exchange server installation requirements that included IIS and Active Directory. These are often considered too cumbersome for hosts running internet facing services. Splitting functionality into distinct roles, allowed Exchange 2007 to provide the first DMZ friendly solution. The Edge server role was thus born, an SMTP transport where email hygiene applications filter emails before allowing entry and exit to/from the internal network. Today we walk through the installation of an Exchange Edge server. We also configure this to connect to the Exchange servers running internally. Network Layout We start our walk with a look at the network layout. A typical DMZ is shown below. Internet originating email is received by the Edge server. If accepted this is rel

Upgrading from Exchange 2003 to 2010 Microsoft Exchange Server 2010 brings a new set of great technologies. No surprise many are excited and looking forward to plan and deploy this new messaging infrastructure. Today we cover the basic steps that should be performed in organizations currently running Exchange 2003. Prerequisites Prerequisites that must be met before we start the deployment: Windows Server 2003 SP2 or later, Global Catalog servers in each site where Exchange Servers are located and Windows Server 2003 forest functional level. Exchange 2003 Organization must be in native mode, with Exchange 2003 SP2 installed In place upgrade is not supported, thus new hardware should be installed for the Exchange 2010 Servers. Hardware requirements may be found at the following link: http://technet.microsoft.com/en-us/library/aa996719.aspx Operating Systems supported are Windows Server 2008 SP2 64-bit and Windows Server 2008 R2 64-bit Standard or Enterprise. Please note that

Introduction In part 2 of this multi-part article, I showed you how to create and configure the virtual services required for the Exchange 2010 protocols/services as well as how you went about and changed the external and internal URLs for each respectively. In this part 3, I will show you how to enable SSL offloading so that SSL sessions are terminated on the HLB solution instead of on the Exchange 2010 CAS servers in the CAS array. Why enable SSL Offloading? There are several benefits of enabling SSL offloading when using a hardware load balancer (HLB). When you enable SSL offloading you terminate the incoming SSL connections on the HLB instead of on the CAS servers. By doing so you move the SSL workload (encryption and decryption tasks) which are CPU intensive from the CAS servers to the HLB device(s). With CAS servers getting more and more responsibility with the introduction of new features such as MailTips, Move Request Service (MRS) and because it now also is the endpoint