Exchange

SnapManager for Exchange fails to run scheduled snaps after running an upgrade to 6.0.4

Sometimes fixes & patches introduce another set of issues that will give way to another set of new patches and fixes.

In our case, it was our upgrade to SnapManager for Exchange( SME) 6.0.4 which had fixes to some bugs we were facing. Everything seemed to go real well, all the upgrades on the Exchange 2010 DAG member servers didn’t hiccup one bit. This was too good to be true, an upgrade of SME and no issues so far. I had my fingers crossed and was hoping for the best, maybe luck would be in our corner.

No Joy…

After completing the upgrade on all servers I needed to run a test of some exchange snaps. Got to make sure it works right? I first started out running manual snaps on all the databases on each node. Those worked great, No Problems.

So onward to the next test which was to kick off a scheduled snap of the DAG databases. After kicking off a scheduled snap through task scheduler the snaps failed to run. After some digging around and a few more tests, my co-worker discovered that there is bug when you upgrade to SME 6.0.4 which causes scheduled snaps to fail.

According to Netapp’s KB 649767 article it has to do the value “0” is not selectable in the “retain up-to-the-minute restorability” option in the GUI of this release like it was in previous releases.  When running the snaps through the GUI of SME 6.0.4 , you can manually enter the value “0” and the run the job immediately, backups will work. The issue occurs when SME creates a scheduled job; it creates the job with wrong parameter , it be should be NoUtmRestore if you don’t want to retain any transaction logs.

http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=649767

SME604_a

Getting Backups to work again…

To get scheduled backups to work again you will need to do one of 2 things:

  • Change the -RetainUTMDays and -RetainUTMBackups from something other than “0”. Changing the value to something other than “0” will retain your transaction logs for the specified value
  • If you don’t want to keep any transaction logs, manually modify the scheduled job and remove the -RetainUTMDays or -RetainUTMBackups parameters then replace with NoUtmRestore.
    • If you are running a DAG remember you will need to modify the scheduled job across all DAG members that have the scheduled job.

SME604

Advertisement

Using Custom Filters For Your Exchange Dynamic Distribution Groups

Dynamic Distribution groups are Distribution groups that dynamically add members into the group based on a certain set of filters and conditions, when an email is sent to the group. These are great for mass mailing a group of users that change can often and managing the group manually would be difficult to maintain.

Exchange offers 2 ways of creating these groups; you can use the EMC/ EAC or PowerShell. I have found that the majority of cases for Dynamic Distribution can be created using the EMC/EAC, which offers the following set of pre-canned filters and conditional.

  • IncludedRecipients
  • ConditionalCompany
  • ConditionalDepartment
  • ConditionalStateOrProvince
  • ConditionalCustomAttribute( 1–15)

There are times that this pre-canned list just doesn’t fit the bill. Let’s say you need a Dynamic Group that filters on users from a certain country or even a particular job title?  PowerShell to the rescue!

PowerShell offers the pre-canned filters as well as any of the account attributes that a user account would have, giving you a lot more freedom to create some customized Dynamic Distribution Group. Please note that you cannot combine pre-canned conditional filters and custom Recipient Filters in the same query.

For example, to create a Dynamic group for mailbox users only in a particular country and company, let’s say the US, use the following cmdlet:

New-DynamicDistributionGroup -Name "TestGroup" -Alias "TestGroup" -OrganizationalUnit "your/OU"-RecipientFilter {(RecipientType –eq  “UserMailbox”) -and (CountryOrRegion –eq “United States”) -and (Company –eq “mycompany”)}

If you have an existing group that you just need to modify to become custom use the Set-DynamicDistributionGroup cmdlet:

Set-DynamicDistributionGroup -Identity "TestGroup" -RecipientFilter {(RecipientType –eq  “UserMailbox”) -and (CountryOrRegion –eq “United States”) -and (Company –eq “mycompany”)}

Note that when creating your Dynamic Distribution Group using PowerShell you cannot combine pre-canned conditional filters and custom Recipient Filters. A list of all the available filterable properties  parameters can be found on TechNet’s site.

http://technet.microsoft.com/en-us/library/bb738157(v=exchg.150).aspx

Exchange 2010 and Active Directory Operation Failed on DC errors

An annoying problem that I have seen since we upgraded to Exchange 2010 is when in the Exchange Management Console (EMC) , you are not able to perform certain tasks because a DC could not be contacted .The domain controller in the error is usually one that has been demoted from your environment but sometimes not.  The issues can also occur after recent changes to a DC, which causes the EMC to lose contact with the Domain Controller

When this particular scenario was first noticed , it puzzled us because the DC in question  was still  running and Exchange was able to discover it. We did all the typical AD and exchange troubleshooting steps, checked permissions, AD replication, etc., but none these steps fixed the issue, the tech was still not able to create accounts.  After some more digging around we later found out some FSMO roles were removed from that DC. Aha! A major change to the DC.

Common error messages may contain  “Active Directory operation failed on Dcxxxx” or “ LDAP server was unavailable”. When the problem occurs  you are not able to perform certain actions in the EMC, such as creating accounts, mailbox moves, basically any operation that requires contact with the DC.

 An example of an error is shown below:

EMC

So what’s the problem you ask?

The problem is a result of the Exchange Management Console caching the domain controller details in the MMC temp files. It caches the data but it’s not smart enough to update the data or locate another DC. To fix the issue you have to remove the MMC cache file from the users profile.

Use the following steps to clear the EMC MMC cache file:

1. Close the EMC if you have it open
2. Go to the User’s profile directory and delete the Exchange Management Console file.
3. File location can be found here:

      • C:\users\<specific user>\AppData\Roaming\Microsoft\MMC\Exchange Management Console

EMC2

4. Reopen the EMC

See Microsoft KB article http://support.microsoft.com/kb/2019500

Message restrictions on your Exchange groups preventing emails to be received?

A common problem I get support tickets on is distribution groups not receiving emails from non-Exchange systems. There can be various reason for this, but the first thing I do is check the mail flow settings for the group to determine if the group is restricted to only authenticated users.

When groups are created in Exchange 2010, the default settings are applied and off you go, ticket closed. What is often overlooked are the mail flow settings for the group. The mail flow settings control who can send to the group, which senders to reject messages from and require that all senders are authenticated. Typically this not an issue if you’re sending emails to the group in Outlook, but if you want to send emails to this group from outside of the Exchange system, you will want to make sure that this is not enabled. When the “require that all senders are authenticated”  is enabled it prevents any users that don’t have valid logon credentials in your organization from sending emails to this group. If you have servers in your environment that need to send emails to an Exchange group, you will want to disable this setting since that server is not authenticating. If the groups were created prior to Exchange 2010, this setting was not enabled by default therefore there were restrictions.

You can disable the setting by 2 ways, through Powershell or the Exchange Management Console (EMC).

To disable the setting in the EMC:

Go to the group properties in the EMC > Mail flow settings > clear the checkbox on “Require that all senders are authenticated”

Mailflow1

To disable the setting in Powershell:

Set-DistributionGroup -Identity <DistributionGroupIdParameter> -RequireSenderAuthenticationEnabled $false

Mailflow2a

How to set an Out of Office Message in Powershell

Something that I get asked quite often from our techs is  “can I set Userxx’s Out of Office message?”. Luckily with Exchange 2010, any tech or admin with the correct permissions can easily do that. There are 2 ways ; via the Exchange Control Panel( ECP) or through Powershell. I personally think it’s easier to do it through the shell but the ECP has it advantages too. For instance the ECP can be accessed on any web browser and if you’re configured correctly you can even access it outside of your internal company network.

If you’re like me and you like quick & easy then using Powershell maybe the method for you. To set the OOF using Powershell run the following commands.

Set-MailboxAutoReplyConfiguration pschmitt@youremail.com –AutoReplyState Scheduled –StartTime “1/8/2013” –EndTime “1/15/2013” –ExternalMessage “Type External OOF message here” –InternalMessage “Type Internal OOF message here”

You can save this command in a text file and next time you need to set the OOF simply modify the email address and message then copy & paste directly in powershell.

Now wasn’t that simple?