Posts Tagged Exchange

Exchange 2010 EMC not opening “The WinRM client cannot complete the operation within the time specified”

When I open the Microsoft Exchange EMC on a server, the following error message displayed.

Initialization failed

The following error occurred when getting management role assignment for ‘domainname.local/MyBusiness/Users/SBSusers/Administrator’:

Processing data for a remote command failed with the following error message: The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network and firewall exception for Windows Remote Management service is enabled. For more information, see the about_Remote_Troubleshooting Help topic.

Click here to retry

There are no additional errors in the Eventlogs. The server is running Exchange 2010 SP2. No proxy configured. Windows update is up-to-date. Windows firewall is off.

Exchange is still functioning but there is no management of the service.
The first lead I found here, suggested antivirus.

https://social.technet.microsoft.com/Forums/exchange/en-US/a675a48e-75a3-43c7-b99b-ec86527adb1d/emc-initialization-failed-with-winrm-error-exchange-2010-sp2?forum=exchange2010

As the site is using Trend Micro Worry Free Advanced, I opened the TMWF console, created a new Server container, dragged the server into it from the old container, refreshed the client on the server and can now access the EMC.

Now that I know what caused it, looking over the Trend Knowledge base reveals http://esupport.trendmicro.com/Pages/Unable-to-access-Exchange-2010-Management-Console-.aspx

The issue of not being able to open the Exchange Management console can occur when there is no Internet Connection after a server restart.
This can affect any server coming up without an internet connection as the default configuration of the virus software on the server is configured to look at the internet before allowing connection to the EMC
You can change this behaviour by following the steps in the Trend KB article.

The issue occurs because the Proxy hooks the Exchange 2010 management console query URL and it fails to get score from the Internet because there is no connection.

To resolve the issue:

  1. Ensure that the Exchange Server has Internet connection.
  2. Log on to Worry-Free Business Security (WFBS) web console.
  3. Go to Security Settings > Add group.
  4. Under Group type, select Servers.
  5. Specify a name for the group.
  6. Click Save.

Note: The created group will have the default settings if the Import settings from group check box is unticked.

  1. Disable the Web Reputation and URL Filtering feature for the newly created group.
  2. Go to Security Settings, then select the new group.
  3. Click Configure.
  4. Select the Web Reputation tab and unmark Enable Web Reputation for In-Office and Out-of-Office.
  5. Click Save.
  6. Select URL Filtering and unmark Enable URL Filtering.
  7. Click Save.
  8. Move the Security Agent of the Exchange 2010 Server in the previously edited group.
  9. Go to Security Settings and select the server group where Exchange Server 2010 is listed.

Note: This step refers to the Exchange Server Client/Server Security Agent and not the Messaging Security Agent.

    1. Drag and drop the selected Exchange Server to the group you created.

 

Tags: , ,

What happened to my CDO in Exchange 2007 SP1 ?

I write a number of VBS scripts to help perform functions on servers. Some of these send me alert emails using CDO.
I have had no issues with VBS files and CDO access however I started compiling to EXE files and everything changed.  

The VBS scripts either use:

set objMsg = CreateObject(“CDO.Message”)

With objMsg
.To = “email address”
.From = “email address”
……. etc …………….
end with

Or more chaotically

Set objMsg = CreateObject(“CDO.Message”)

objMsg.From = “email address”
objMsg.To = “email address”
etc

To send me the results of some test.

This has been working for ages, and continues to work however, someone pinched my code. I need to start protecting it. I can’t resort to compiling to vbe (Easily unencrypted) so I instead found a solution to compile to exe files.

The exe files worked for a while (over a year) and suddenly, they started failing.

They brought up “Error”, the line number that broke but no error description. The vbs files still work fine.

I looked at the line that fails.

It is the .To = “email address” or objMsg.From = “email address” in my above samples.
i.e. the line that tries to do the first action with CDO.

I tried all kinds of error trapping/reporting to bring up an error message. Nothing. It is as if CDO is not there.

But only for exe files ?

I tried making the exe file a trusted file. I allowed it through the firewall and tried loads of other actions and tests.
It does not work.

I ran filemon/regmon and process monitor and compared a working and failing server.

I wrote a test script that has about 10 lines and just tries to send an email. As a VBS, it is fine. As an EXE it fails.
These 10 lines created over 30,000 entries in Process Explorer.

Now started the long trawl through the output, comparing each section.

On the machine that works, the exe gets access to the registry, looks for the CDO handler for Win32, finds cdosys.dll and executes.

On the machine that fails, it looks for the win32 dll for CDO, falls back to win16 and then fails.

 It seems some key information for CDO is missing in the registry.

I ran the vbs file. It looks for the CDO handler for Win64, finds cdoex.dll. It seems cscript and wscript want to use the Win64 registry key, not the Win32.

Now I see why the exe could potentialy fail and yet the vbs works. They access CDO via 2 different ways.

A little more research and I found that Exchange 2007 SP1 can loose the 32bit CDO reference.

All I needed to do was drop to a cmd prompt.

C:\Windows\syswow64\regsvr32 cdosys.dll

All fixed !

Tags: , , , ,

Exchange and Heartburn

Saturday night (just past) was a nice evening. Nothing to complain about, all going well. Waking early Sunday morning I noticed my iPhone was not connected to the Exchange store at my office (ActiveSync).

I remoted into my workstation at work and noticed that Outlook was empty and trying to attach to the information store. I logged onto the server and found the Exchange Information Store, System Attendant and Pop3 connectors had stopped. I also noticed the pop up telling me that Microsoft had updated the server and had to complete a restart. This was likely after automatic critical updates Sunday 3 am (Wsus).

I started the services and went into Outlook. As we monitor all our clients servers on port 25 and by other means, the deluge of emails and alerts I had be unaware of, was starting.

Almost all of our SBS 2008 servers running Exchange 2007 had stopped receiving email. One in particular had also dropped RWW and VPN access.

With most of them, restarting the stopped services fixed things. With a few others I had to kick over the Exchange Topology service.

We also had 2 SBS 2011 (Exchange 2010) with the Pop3 connectors stopped.

After a massive session of Remote desktop, VPN and RWW, we managed to get all the servers email working again.

Now we need to look at the updates and identify what caused this. If the servers had gone through a second restart, they would have been fine.

EDIT: Reports coming in now include EBS server as one of the servers affected by this.

Tags: , ,

So Exmerge is not going to natively work with Exchange 2007/2010. How do I export all the email? How do I move to a new server?

We have all grown to love and trust the Exmerge tool (It enables the import and export of emails between mailboxes and personal folder files (.pst). Exmerge is often used to perform brick level backups, enabling the backup/restore of individual mailboxes).

We used to manually export the clients Public folders from within Outlook and then magically rip out the remaining mailboxes behind the scenes (Overnight).
As long as the mailboxes are less than 2 Gb, as this is a limit with the PST files created with Exmerge, everything was automated and happened invisibly.

Now, we have less of a limit, as the newer PST files are limited to 20 Gb but … we don’t have Exmerge.

If you are using PS T’s to migrate mailboxes from one Exchange server to another, I have some options for you. You still have the move-mailbox procedure as an option but many of us end up in situations where the manual PST export is the Tool of choice.

With all of these options you still end up with a PST and there is a certain issue with replying to old email and calendar appointments that recur.
Look at http://blogs.technet.com/b/sbs/archive/2009/05/21/cannot-reply-to-old-emails-or-modify-old-calendar-items-after-pst-mail-migration.aspx

So, what do we do now?

Option 1: Sit at every PC and manually export all mailboxes to PST

Open Microsoft Outlook as each user account and resource mailbox on the network, manually export to PST.
On the new system, manually import each mailbox PST file back into a new MAPI profile for each user (Outlook is needed on a workstation).
Warn each user that replying to old internal emails might lead to failed email delivery. ( … and don’t bring over any nk2 files)

Job done but takes a long time. Also remember, Outlook 2003 versions and earlier are limited to 2 Gb PST files.

This is a boring tedious task.

Option 2: hack about with Exmerge.

The truth is that Exmerge does work with Exchange 2007. You don’t even need an Exchange 2000/2003 server within the company structure.
You can use the Exmerge included with the Exchange 2003 Tools but this needs to run from a client machine. You can’t run it on the server.

Exmerge 2003 requires the Exchange 2003 System Management Tools to be installed and for this to work you need IIS (Internet Information Services Snap-In) and some other tools.
You need to download and install the Windows Server Administration Tools Pack AdminPak.msi.
You then need an Exchange 2003 CD (the hard part). (You may also need a CD Key, the harder part). Select to install only the Microsoft Exchange System Management Tools component.

The final step is to check the Exchange service pack level and install this to your new management Pc.

The latest Exmerge is available for download from http://www.microsoft.com/technet/prodtechnol/exchange/downloads/2003/tools.mspx

Extract out the Exmerge.doc, Exmerge.ini and Exmerge.exe files and copy all files to the Exchange bin directory created by the Exchange System Management Tools installation.

The user account running Exmerge now needs access rights to the processed mailboxes. (Much the same as it did in Exchange 2000/2003)

We need to delegate the user with ‘Exchange View Only Administrator’ role and give the user Send As and Receive As permissions over the mailbox store. (Same requirements as in Exchange 2003 etc, different procedure).

Note: as with previous versions of Exchange, the Administrator and Administration groups inherit a deny security setting for the Send As / Receive As permissions. The user we create cannot be an administrator.

 At the Exchange Server, delegate ‘Exchange View Only Administrator’ control to the user you created.

Open the Exchange 2007 Management Console and select ‘Organization Configuration’

At the right-hand Action pane, click on ‘Add Exchange Administrator’

Add the account you want to use.

PowerShell –
Add-ExchangeAdministrator -Identity ‘domain.local/Users/ExMerge’ -Role ‘ViewOnlyAdmin’

You can now log your management PC on as the user, open the Management tool and it should look like the old ESM in Exchange 2003.
We now need to give the Exmerge user Send As and Receive As permissions on the Mailbox Store.

PowerShell –
Get-MailboxDatabase -identity “servername\First Storage Group\Mailbox Database” | Add-ADPermission -user “domain\ExMerge” -ExtendedRights Receive-As, Send-As

You can now run Exmerge from your management PC against Exchange 2007. Run Exmerge from within the bin folder, put in the domain information and user information as normal, select the two step process select all the mailboxes and export to your selected location.

It would be a good idea to look in the ESM at the mailbox sizes and make sure that they are all under 2 Gb.

Option 3: Third Party tools

There are lots out there. Ontrack PowerControls has worked for me in the past and can allow you to crack open an offline EDB exchange file. This is my favorite method and the most expensive. These tools have saved my bacon in many high stress recovery situations.

Option 4: Pure PowerShell

Please note: Export/Import to PST must be run from a 32 bit client machine with Exchange Management Tools installed (Version Exchange 2007 SP1 or later).  The 32bit requirement comes from a dependency with the Outlook client.

Install Outlook 2003 SP2 or Outlook 2007 on your management PC.

You can download Exchange 2007 Sp1 32-bit (E2K7SP1EN32.exe) from http://www.microsoft.com/downloads/details.aspx?FamilyID=6be38633-7248-4532-929b-76e9c677e802&displaylang=en
You will need to install PowerShell (It is a part of Windows 7) http://support.microsoft.com/kb/968930
You will need MMC 3.0 http://support.microsoft.com/kb/907265 

Once PowerShell and MMC 3.0 is all working on your management PC, run E2K7SP1EN32.exe and run the setup.exe. Do a custom installation. Select only the Exchange Management tools.

 After many system updates and a few reboots later you are ready to check all your permissions and do the PST export.

You need the following:

  • The user running the task must be an Exchange Organization Admin or an Exchange Server Admin on the server where the mailbox to export/import lives.
  • The user running the task must also have full mailbox access to the user mailbox you want to export/import.
  • To use the export-mailbox cmdlet, the source mailbox must reside on either Exchange 2007, Exchange 2003 SP2 (or later), or Exchange 2000 SP3 (or later).
  • To use the import-mailbox cmdlet, the target mailbox must reside on an Exchange 2007 mailbox server.
  • You cannot import or export data to or from a mailbox in a Recovery Storage Group
  • You cannot import or export data to or from a public folder.

To get started, you need to grant your user access. I create an Exmerge account in the Active Directory to do this with.
You can use the Exchange console to set the permissions . Use the Manage Full Access permission tool on the mailboxes node.

PowerShell –
Get-Mailbox | Add-MailboxPermission –user Username –AccessRight FullAccess –Inheritancetype all

Now you need to export the mailboxes to PST Files

PowerShell –
Export-Mailbox –Identity <mailboxUser> -PSTFolderPath <pathToSavePST>

PSTFolderPath must be a full path pointing either to a directory or to a (.pst) file. If a directory is specified a PST file named after the mailbox alias will be used as the target of the export. Note that if the PST file already exists the contents of the mailbox will be merged into it.

I have found in practice that the PST file that is produced is larger and contains more email than the mailbox. Maybe it pulls out the item retention items as well ?

This seems rather painfull in comparrison to Exmerge. That was a set and forget and run over night tool. This seems to be mailbox by mailbox?
Try this

PowerShell-
Get-Mailbox -Database “mailbox database” | Export-Mailbox -PSTFolderPath D:\PSTs

Now we are at the new destination domain. The second half of the Exmerge 2 step process. You can import all the email pst files one at a time in Outlook logged in as each user or import with Powershell.

PowerShell-
Import-Mailbox -Identity <mailboxUser> -PSTFolderPath <PSTFileLocation>

PSTFolderPath must be the full path to the directory where the .pst file lives or to the (.pst) file itself. In the case where PSTFolderPath points to a directory the cmdlet will try to match the mailbox alias with the name of an existing .pst file in the specified directory and import the content of that file.

When bulk importing mailboxes the PSTFolderPath must forcefully point to a directory and the task logic will try to match mailboxes alias with the .pst file names under that location. If no match is found for a particular mailbox, that mailbox will be skipped.

Powershell –
Get-Mailbox -Database “mailbox database” | Import-Mailbox -PSTFolderPath D:\PSTs

Let’s say you want to get fancy.  This is the power of PowerShell over Exmerge. Lets filter content in Export/Import to PST files.

Export/Import to PST support the following filters: Locale, StartDate, EndDate, ContentKeywords, SubjectKeywords, AttachmentFileNames, AllContentKeywords, SenderKeywords, and RecipientKeywords.
Example: Import only those messages that were created between 1/1/10 and 30/1/11 and contain the word “Exmerge” in the subject and any of the words {“ESM”,”2003″} in the body.

PowerShell-
Import-mailbox -Identity user -PSTFolderPath D:\PSTs -StartDate 1/1/10 -EndDate 30/1/11 -SubjectKeywords:’Exmerge’ -ContentKeywords:’ESM’,’2003′

Much better than Exmerge. I think you can start to see many other uses for PowerShell.

The last option (option 5) is a Migration. That is a big topic and a whole other post.

 It belongs in this post but this one is long enough and I have a headache !

Tags: , ,