Send an email via the Send-MailMessage cmdlet anonymously

If you have Powershell scripts that run as a scheduled task and if they send an email, you may notice that they actually connect using authentication to the Receive Connector in Exchange 2010.

If, however, you want the email to come from a different address such as ServerName@domain.com instead of the actual email address of the service account and do not want to give the service account an email address, you may want to get the Send-MailMessage to send anonymously and not log in.

I have found the following to work OK:

$User = “anonymous”
$PWord = ConvertTo-SecureString –String “anonymous” –AsPlainText -Force
$Creds = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $user, $pword

Send-MailMessage -To recipient@domain.com -From sender@domain.com -Subject “Subject” -Body “Body” -SmtpServer “server” -Credentials $creds

Moving mailboxes results in MapiExceptionInvalidParameter Unable to modify table

When moving a mailbox from Exchange 2003 to Exchange 2010, you may see the following error on certain mailboxes and the move request fails at 95%

Error details: MapiExceptionInvalidParameter: Unable to modify table.

If you click on the option to view the move log, scroll to the bottom of the file and see if you have something similar to

Folder: ‘/Top of Information Store/Archived Emails/Inbox’, entryId [len=46

If you do, get the user to create a new folder in their mailbox under a different name, drag all email from that folder to the new one and delete the old now empty folder.  Try moving the mailbox again and it should move without loss of email – there is no need to delete all email in that folder.

 

Delete a specific message from mailboxes in Exchange 2010 SP1

I have come across a lot of misinformation or incorrect tutorials regarding how to do this, so have posted the procedure I use below.

Take this example:

• A user called John.Smith@domain.com sends an email to the Distribution Group Sales.Staff@domain.com by mistake and HR request it is removed from all mailboxes and sign off on it – the HR part is important (well I suppose it depends where you work!)
• The attachment is EveryonesPay.xls
• The subject was Pay rates
• It was sent on June 10th 2013

To remove this email perform the following:

1. Your user account needs to be a member of the Discovery Management group or mailbox searches will not work (even if you are an org admin)
2. Your account needs to be able to run the New-MailboxExportRequest cmdlet which even the org admins cannot run by default
3. To add the org admins group with permissions for Mailbox Import Export (best practice is to create a new group and add yourself to that seperate group, but this is for simplicity)
   New-ManagementRoleAssignment -Name “Import Export Mailbox” -SecurityGroup “Organization Management” -Role “Mailbox Import Export”
4. After doing the above you should be able to open the Exchange Shell and have access to the Search-Mailbox and the New-MailboxExportRequest cmdlets
5. First job is to run a report to make sure you have the search string correct and that it only shows one email for each mailbox unless they have forwarded it and it sits in their sent items too (you HAVE to be careful to get the search string correct – if you are not in the USA then use a normal date format DD/MM/YY)
   Get-DistributionGroupMember “Sales Staff” | Search-Mailbox -SearchQuery “from:John.Smith@domain.com”,”sent:12/06/13″,”subject:pay rates”,”attachment:everyonespay.xls” -TargetMailbox yourmailbox@domain.com -TargetFolder “SearchResults” -logonly -LogLevel full
6. This saves time (you can specify a Get-Mailbox -ServerName MBX01 command and search ALL mailboxes, but why waste time searching mailboxes that are not part of the distribution group – UNLESS of course you think people may have forwarded it on to people!)
7. You will be emailed a report with a CSV file showing how many results for the match were found in the target mailboxes
8. If you are happy that the report contains only the email you are after – ie your search string is accurate – you can delete the email using
   Get-DistributionGroupMember “Sales Staff” | Search-Mailbox -SearchQuery “from:John.Smith@domain.com”,”sent:12/06/13″,”subject:pay rates”,”attachment:everyonespay.xls” -DeleteContent
9. You will be prompted for each mailbox or can select yes to all
10. Wait a while and perform the search again and you should see 0 results
11. The main part of the above is the search string and running the logonly part first – if you jump straight in to the delete phase and do not run a test search first (even if it may take a while) you run the risk of deleting valid email

Exchange 2010 SP3 rollup 1 causes messages to stick in the Poison queue

It’s always worth monitoring the Exchange Team Blog for each update released for Exchange 2010.  Within a couple of weeks you will see from the comments section which problems the update introduces and without fail, each update for the last year or so has fixed problems but introduced different ones.

Exchange 2010 SP3 Rollup 1 was relased a couple of weeks ago and this is no exception.  If you use a transport rule to add a disclaimer to messages, then for the moment stay away from Rollup 1 as it causes outgoing messages to stick in the Poison queue.  Update 1 does fix a whole bunch of existing bugs which have been around for a while (which is a good thing!) but it is a weight game and depends if the new bugs affect you or not.

You can see many comments about this from the MS blog post about the update release:

http://blogs.technet.com/b/exchange/archive/2013/05/29/released-update-rollup-1-for-exchange-server-2010-sp3.aspx

Can’t connect to Exchange EWS? Check the access policy

If you are in an unknown Exchange 2010 environment and for some reason cannot connect to EWS, check if the previous Exchange admin has set a EWS access policy which limits what can connect to Exchange via EWS.

Run the following to check if it is set at a high level:

Get-OrganizationConfig | Select *ews*

Run the following to check if it is set at a mailbox level if you have a certain mailbox with problems:

Get-CASMailbox MAILBOXNAME | Select *ews*

The default is blank for all values:

EwsEnabled                 :
EwsAllowOutlook            :
EwsAllowMacOutlook         :
EwsAllowEntourage          :
EwsApplicationAccessPolicy :
EwsAllowList               :
EwsBlockList               :

Use powershell to get mailbox sizes from Exchange 2003

I put together this quick one liner as a useful way to grab a list of mailboxes from an Exchange 2003 server instead of manually exporting them from the Exchange 2003 management console.  This can be run remotely from a member server so saves having to install anything on the Exchange 2003 server.  Under Exchange 2010 you can simply run Get-MailboxStatistics, but this won’t work for Exchange 2003.  This is useful when planning mailbox moves to new Exchange 2010 databases based on current size.

Get-WmiObject -ComputerName EXCH2003SERVER -Namespace root\MicrosoftExchangeV2 -Class Exchange_mailbox | Select MailboxDisplayName, StorageGroupName, StoreName, {[Math]::Round($_.size / 1024)} | sort-object MailboxDisplayName

You can pipe to a CSV file using Export-CSV or of course modify to requirements sorting by size, etc.

Remove direct booking settings after migrating to Exchange 2010

Microsoft have just published a new blog post today about how to remove direct booking access from calendars following a move to Exchange 2010.  Before today you had to manually log on to each mailbox, open Outlook and untick the booking options which could be a real pain if you had lots and lots of resource and room calendars.

If you have moved to Exchange 2010 with Outlook 2010 and now use the Resource Booking Attendant which is much more functional and stops double bookings occuring (because users have no rights to resource calendars anymore) then you can now remove the direct booking option without having to manually go to each mailbox – a god send if you have lots of them!

See the technet blog post here about it – http://blogs.technet.com/b/exchange/archive/2013/05/09/use-exchange-web-services-and-powershell-to-discover-and-remove-direct-booking-settings.aspx

Exchange 2010 baseline performance scan

When installing a new Exchange environment it is important to obtain baseline performance scans following jetstressing the storage.  This allows you to compare performance with a handful of test users on the servers and in stages as you move people across to see how the server is scaling.  You can also refer to these reports in years to come if required and compare them to todays performance.

Rather than messing about with manual perfmon settings, you can perform a baseline using Exchange 2010 built-in tools.  These basically run a perfmon task against each Exchange server, but without the hassle of you manually setting up what counters you require.  You can also export the scans and store them safely for importing in at a later date if needed or if you need to send them to someone.

To do this:

1. Open the Exchange 2010 console
2. Select the Toolbox tab
3. Select the top option Best Practices Analyzer
4. This runs up the standard BPA tool
5. Select to check for updates to make sure you have the latest version
6. Select a domain controller to connect to
7. Give the scan an identifying label such as Baseline 010513
8. You can  put a tick box into each Exchange server you want checked and the scan will report on each of them
9. Select the Health Check option and put a tick in Performance Baseline (2 hours)
10. Select the speed of your network
11. Click Start Scanning

The scan will take just over 2 hours and when it is done you can view the report.  It will list all the Exchange servers you selected along with a load of performance counters listed average and max.

If you want to export the scan to save it somewhere:

1. Click on Select a Best Practices scan to view
2. Select the baseline you created earlier
3. Select Export this scan and choose a file location
4. You can import it at a later date by clicking the top-right button Import scan

Using EventCombMT and LockoutStatus with 2008 R2 to find account lockout events

EventCombMT is a Microsoft application available here – http://www.microsoft.com/en-us/download/details.aspx?id=18465

If you have no 3rd party AD auditing tools and want to find out what machine an account is being locked out on, perform the following:

1. Install ALTools (This tool can be installed on a member server saving you the hassle of installing software on a domain controller)
2. Open EventCombMT.exe as an Administrator (and an account that has rights to read a domain controllers security logs)
3. In the Select To Search box, right click and choose Get DCs in Domain
4. Highlight the DCs that you wish to search by clicking or shift+click to select more than one
5. Under Choose Log Files to search ONLY tick Security
6. Under Event Types ONLY tick Success Audit AND Failure Audit
7. For Event IDs type in 4740 (NOTE: The event ID is different for Server 2003 but this is for 2008 R2)
8. You can set a date range by selecting Options and Set Date Range (normally the last 24 hours is enough)
9. Click Search to begin harvesting the events
10. If matching events are found the Matching Events Found figure will go up
11. You can stop the search at any time by hitting Quit as this does not clear the results
12. The folder C:\Temp will open and you will see the matching events in text files for each DC named DCName-Security_Log.txt

LockoutStatus.exe is included with ALTools and can be used as follows:

1. Open LockoutStatus.exe
2. Click File and Select Target
3. Type in a target username – the account whose status you wish to view
4. The target domain is filled in with your default domain
5. If you are not running the tool as the correct AD admin account, specify the alternate credentials
6. Click OK
7. Each DC in that domain is checked and the status of that account on each DC is shown along with the original DC that locked the account

Default authentication settings for Exchange 2010 IIS virtual directories

Useful for when someone has fiddled with the default permissions:

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