Subscribe by Email

Your email:

ms exchange servers

describe the image

Follow ENow

Solutions Engine Blog

Current Articles | RSS Feed RSS Feed

The ESE Consultants’ Corner: Third Edition

 

Hello and welcome to the Third edition of the Consultants’ Corner.

In this edition, I will address some of the questions that have reached me through “I have heard that. . .” statements. Unfortunately, in our field some people are reluctant to admit they might not know the answer, and instead give false or misleading statements and opinions. In an effort to help you avoid being a victim to such misguided answers, I will share with you some common misconceptions that I have encountered with my own consulting clients.

I have heard that I can’t upgrade from Exchange 2007 to 2010 in place, and that the same is true for OS (I cannot upgrade from Windows 2008 SP2 to Windows 2008 R2.) Is this true?

The first part is correct, but the second part is only partially correct. Some applications, like Exchange, do not support in place OS upgrade, so you must bring in new hardware, install the new OS on it, and shift the application from the OLD system to the NEW system. Other applications support in-place OS upgrades, such as Domain Controllers and file servers.You must know the application being used, and always check its supportability for in-place OS upgrades. Be cautious as some people get confused between the Exchange OS upgrade statement and the general in-place upgrade statement.

I have heard that I cannot use my SAN as a storage device with Exchange 2010, but I have invested a lot in the SAN. What should I do?

The new Exchange 2010 Architecture makes Exchange 2010 deployment possible on SATA-II disks. However, that does not mean that Exchange 2010 will not benefit from the SAN performance edge. You can still use the SAN and benefit from it.

I have heard that we need the FSW when we deploy a DAG. I am planning to deploy 3 node DAG clusters, but where should I place the FSW?

You do not need the FSW if you deploy an odd number of cluster nodes since with an odd number you can have the majority. The FSW is required for even number of nodes since you might get an equal number of nodes in each site and thus will not be able to form majority which will cause the cluster to fail. DAGs uses the MNS (Majority Node Set) quorum model so when the cluster node can form majority, they can start the cluster service.

I have heard that Exchange 2007 and 2010 introduce database portability, so instead of moving mailboxes can I copy the EDB file, import to an Exchange 2010 mailbox server and then be done?

DB portability is a nice feature that enables you to move EDB files between servers in case of failure and import them to a new server on different HW, but this can’t be done between different versions of Exchange. Thus, EDB files from Exchange 2007 must be imported to an Exchange 2007 server. You cannot import them to an Exchange 2010 server.

I have heard that I need to buy special hardware to load balance my Internet connectivity as well as my WAN connectivity. However, I cannot afford those fancy boxes. What I can do instead?

There are some simple tricks that you can use to load balance or failover in case of internet or WAN connectivity problems.

For load balance, you can use TMG 2010 and the built-in ISP redundancy to provide HA and NLB for the network connection. If you load balance internet using other methods then prepare the cash!

For HA there is a simple trick: either use TMG 2010, or configure your router or Firewall (whatever the routing device is) to have 2 static routes with different priority. Make the lowest priority your primary link in case the primary link drops, then the device will use the backup route. This is a simple yet effective option.

I hope these answers helped clarify any misleading statements you may have encountered. If you are not sure about something or have a technical question that has you stumped, let me know! Email your questions to ESE@ENowinc.com.

Make sure you catch my next article where I will share with you some cool Exchange 2010 SP1 features.

Until then, wishing you the best uptimes and the fastest Exchange servers.

Mahmoud

Comments (0)

Remote Shell Connection in Exchange 2010

Monday, June 7th, 2010
By: Exchange MVP Ismail Mohammed
Remote Shell connection is a new feature in Exchange 2010 that enables the administrator to connect remotely to the Exchange server over a LAN (Local Area Network) or a WAN (WideArea Network). The name alone tells you that the remote shell is the part of a PowerShell command.
Before I explain how to manually connect to Exchange Server 2010, let’s recall certain PowerShell basics and discuss the key advantages of this remote shell connection.
With the release of Exchange 2007, we had two modes to access the Exchange database: the first being the Exchange Management Console and the second the Exchange Management Shell. The Exchange Management Console is nothing but GUI interfaces like the Exchange System
Manager in Exchange Server 2003. Exchange Management Shell is powered on Windows PowerShell Technology, which contains Exchange commandlets and custom scripts. If you see the Management Console, however, you will notice it is doing nothing more than driving out the output or input through PowerShell. So what does it mean, ‘Exchange Management console is relying on the PowerShell command only?’
Why do we need Windows PowerShell?
Consider this scenario:
I need customized scripts to address my organization’s requirements. (Something which is not possible from the GUI that we had in Exchange 2003.) In the past, we were forced to use third
party software or VBScripts – both of which posed challenges. Now with the release of PowerShell, we can automate administrative tasks. Since PowerShell has a robust and flexible
scripting platform, we can perform daily tasks that could be done with the Exchange Management Console (EMC) as well as those that could not. PowerShell reduces the complexity of VBScripts by using one line of code in the shell using an object model based on the Microsoft .Net platform.
Now let’s dive into our topic. If you want to connect remotely to the Exchange Server on Exchange 2003 and Exchange 2007, follow these easy steps:
  • Exchange 2003 – Install the Exchange System Management Tool on your workstations and carry out the task.
  • Exchange 2007 – Install the EMC and carry out the task.
What are the advantages of the Remote Shell?
1) You are not required to install EMC tool or Exchange Binaries.
2) This remote shell can be accessed only by authenticated users.
3) The Exchange remote access will not open until the session is open on the client computer; once you close the session, it will disconnect.
Note: All the configuration can be done by PowerShell commands. In other words, it offers a quick installation along with more secure access as compared to previous versions.
Supported Operating Systems:
1) Windows Server 2003 (SP2)
2) Windows Server 2008 (SP1, SP2 & R2)
3) Windows 7 Client
4) Windows Vista (SP1 & SP2)
5) Windows XP (SP3)
Prerequisites:
1) Windows Management Framework installed.
2) Enable Permission for those users.
3) Uninstall previous versions of Windows PowerShell (v2) and Windows Remote Management.
How to enable the remote shell:
1) Enable the user to access the remote shell.
2) Uninstall the previous Powershell and WinRM. (Optional)
3) Install the Windows Management Framework Core.
4) Set the execution policy to allow the script to be downloaded via browser by a trusted publisher.
5) Connect to Exchange remotely via remote shell command.
Each step broken down:
1) Enable the user to access the remote shell
  • Login to Exchange Server 2010
  • Open the Powershell Command and type the following:
  • Set-User UserName -RemotePowerShellEnabled $True
Example : Set-User remuse -RemotePowerShellEnabled $True
Figure1:
2) Uninstall the previous PowerShell and WinRM (Optional)
Click here to learn how to remove Windows PowerShell & WinRM on Windows Vista Windows
Server 2008, Windows Server 2003 and Windows XP.
3) Installation of Windows Management Framework
a) Download the Windows Management Framework Core.
b) Install the WMF Core and restart the computer.
4) Execution Policy needs to be set as Remote Signed:
Before you execute the remote shell command from the PowerShell, it is very important to set
the execution policy to remote signed. (i.e All scripts, as well as configuration files, should be downloaded via the Internet and must be signed by a trusted publisher. By default it will be restricted, so you will get the following error message when you run Import-PSSession $Session)
Import-Module : There were errors in loading the format data file:
Microsoft.PowerShell, , C:\Users\Administrator\AppData\Local\Temp\tmp_bd7275e3-fb76-4325-b4eb-f6e9b1c88b5c_20eckqql.gms
\tmp_bd7275e3-fb76-4325-b4eb-f6e9b1c88b5c_20eckqql.gms.format.ps1xml : File skipped
because of the following validation exception: File C:\Users\Administrator\AppData\Local\Temp\tmp_bd7275e3-fb76-4325-
b4eb-f6e9b1c88b5c_20eckqql.gms\tmp_bd
7275e3-fb76-4325-b4eb-f6e9b1c88b5c_20eckqql.gms.format.ps1xml cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details..At line:3 char:30
+ Import-Module <<<< -Name $name -Alias * -Function * -Prefix $prefix -
DisableNameChecking:$disableNam
eChecking -PassThru -ArgumentList @($session)
+ CategoryInfo : InvalidOperation: (:)[Import-Module], RuntimeException
+ FullyQualifiedErrorId :
FormatXmlUpateException,Microsoft.PowerShell.Commands.ImportModuleCommand
Figure 2:
Follow the steps below in order to allow the scripts to be downloaded:
1) Open the PowerShell command (ensure you have selected RunAs Administrator) and type the following:
Set-ExecutionPolicy RemoteSigned and press enter.
Figure 3:
If you fail to set the above command, you will see an ‘Access Denied’ error. In that situation, follow the below workaround:
HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy”=”R
emoteSigned”
Note: If “ExecutionPolicy” does not exist, create it as REG_SZ with value “RemoteSigned”
5) Connect remotely via Remote Exchange Management Shell:
a) Login to the local computer where you have installed the WMF.
b) Open the Powershell and type the following command:
$UserCredential = Get-Credential
Note: It will ask for user credential as per the below screen.
Figure 4:
c) Then type the following command:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http:///PowerShell/ -Authentication Kerberos
In my case:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://e2k10.happy.com/PowerShell/ -Authentication Kerberos
Figure 5:
e) Then type: Import-PSSession $Session
Figure 6:
If you want to disconnect the session then type: Remove-PSSession $Session
Once you import the session, you are able to execute the Exchange commands remotely
Figure 7:
Reference Article:
Exchange Management Shell: http://technet.microsoft.com/en-us/library/bb123778.aspx

Comments

There are no comments on this article.
Comments have been closed for this article.