A Collection of Random Thoughts

Part of my job involves supporting the Exchange Management Pack for Microsoft Operations Manager (MOM).  In doing so, we sometimes come across things that don't really make a lot of sense (or at least they don't to me).  Take the following scenario.

With MOM, you can create Mailboxes that MOM then uses to make sure it can log on to at specified intervals.  This is performed via a simple MAPI logon.  The Exchange Management Pack has a script that performs this action, and it triggers by default every 15 minutes.  When you deploy and configure the Exchange Management Pack, you can choose to create a mailbox for the entire server (per-server monitoring), or you can create a separate mailbox for every single mailbox store.

When the MAPI logon script runs, it logs an event based on the result.  The expected result is obviously a Success, but if it fails, there are several different reasons this could be occurring.  Many of these errors are easy to interpret, and have prescribed actions that can be done to troubleshoot/fix the issue.

One event that may get logged is a MAPI logon failure because the logon timed out.  At first glance, that may not really make sense - if a logon is going to work, it is going to work.  Keep in mind, however, that MOM uses scripts to perform the tests, and we could simply be dealing with the script taking a long time to run.  This results in a sort of false-positive.  The MAPI logon doesn't actually fail, and no clients are reporting issues, yet you have this glaring error in your MOM console.

The default timeout for the script itself is 30 seconds.  While this is sufficient in most cases, there may be circumstances where 30 seconds is insufficient, and is resulting in the script timing out (even if it is almost done...), which then results in the error being logged to MOM.  The solution is to modify the MAPI logon script itself and increase the timeout value.  In the script, you will find a line

var TIME_OUT_THRESHOLD = 30000

If you change the threshold to a higher value - 90000, the errors will go away because you are giving the script more time to run.

Single Copy Clusters are the continuation of how clustering was implemented with previous versions of Exchange.  It is a standard cluster implementation which utilizes Shared Storage (i.e. SAN) and allows all nodes of the cluster access to the shared storage.  One node of the cluster will "own" the resources for that cluster group, and all nodes of the cluster maintain communication to ensure that the resources don't get mistakenly taken over by another node.  A quorum is used to maintain ownership information.

That being said, Exchange 2007 does make some slight changes to how you must implement the cluster.  I do want to note that setting up a cluster in Exchange 2007 is MUCH MUCH easier, but there are a few *gotchas*.  First, if you are familiar to clustering with Exchange 2003, you may be inclined to pre-create the Cluster Group for the Exchange Virtual Server, and pre-populate it with the Physical Disks you will be using.  Don't.  Instead, all you need to do is create your Physical Disk resources in the default Cluster Group.

An overview of how to install Exchange 2007 Single Copy Cluster on Windows 2003 can be found here.

http://technet.microsoft.com/en-us/library/bb124899.aspx

and for instructions on how to install the Active Clustered Mailbox Role in a Single Copy Cluster, refer to

http://technet.microsoft.com/en-us/library/bb123969.aspx

Once you have finished the Active Mailbox role, you will find that Exchange 2007 setup will create the new Exchange CMS group for you.  The only step that remains is that you need to finalize configuration of the cluster by moving the physical disk resources from the default Cluster Group into the new Exchange CMS cluster group, and then configuring the dependencies as appropriate.  In Exchange 2007, you will have a separate resource for each Storage Group/Mailbox Store, so it is important to make sure that you get the dependencies correct.

OK.  I've heard lots of complaints about Exchange 2007 and the fact that when you run setup, the pre-requisite checks will fail if you have multiple domains in your forest, and one of those domains doesn't have a Windows 2003 SP1+ domain controller.  That's fair enough.  Some of those child domains may not have an existing Exchange server, or may not even host exchange-enabled objects.

As many of you know, we changed the behavior of setup for Sp1, however the documentation still is being misinterpreted.  The new pre-requisite check will now check child domains during the /preparelegacyexchangepermissions portion of setup, and will look for the "Exchange Domain Servers" group.  If it finds that group present, then that domain must contain a Windows 2003 Sp1+ DC.  If you are in this situation, you have 2 options.  If you don't have any Exchange objects in that child domain, AND YOU ARE SURE OF THIS, then you can remove the Exchange Domain Servers group from that domain.  When you then run setup again, that domain will be skipped from the pre-requisite check.

See http://msexchangeteam.com/archive/2007/11/01/447411.aspx for more details around this.

Alright, so now you know about the SP1 install requirements, and when a Windows 2003 Sp1+ DC is required.  The next question is, can I temporarily install a Windows 2003 SP1+ DC in a child domain that I am not ready to upgrade to Windows 2003 yet?  The answer is that this is not a good idea.  In fact, I'd go one step further and say that this will create huge problems.  Let's talk about why.

Exchange 2000/2003 stores exchange-related information in the Personal and Public property sets.  These property sets contain both Active Directory information (such as Street Address, phone number) AND Exchange information (msExchHomeServerName, proxyaddresses).  It was decided that it would be a good thing to have Exchange store it's attributes in a separate Exchange-specific property set, so Exchange 2007 creates two new property sets, Exchange Information and Exchange Personal Information.  When /preparelegacyexchangepermissions is run, part of it's operation is to move the existing Exchange attributes into the new Exchange property sets.

See http://technet.microsoft.com/en-us/library/bb310768.aspx for more information about these property sets.

So what's the problem?  The problem is that these new Exchange property sets can only get replicated between Windows 2003 Sp1+ Domain Controllers.  If you introduce a temporary Windows 2003 Sp1 Domain Controller in a child domain just so you can run setup to install the first Exchange 2007 server, then you later remove it, the other Windows 2000 Domain Controllers in that domain do not know about the new Exchange property sets.  Since the Exchange attributes have already been moved to the new property sets, you can see how this could be disastrous for your company.  Imagine having mailboxes in a child domain and the domain controllers in that domain no longer have any knowledge of any Exchange attributes.  Not Good.

The moral of the story here is to make sure that you understand the pre-requisites and don't shoot yourself in the foot by trying to work around the setup requirements.

By now, you should be familiar with the day to day Powershell commands, so here is one that uses the foreach command.  Foreach is used to loop through a given set of items (an array), and perform an action on each one.

As an example, let's say that you want to perform a Cross-Org mailbox move, but you want to use Get-Mailbox first to get a list of mailboxes.  Just using the standard filtering, you have limited options.  You can filter 1. By a specific Organizational Unit; 2. By a specific Exchange server; 3. Don't filter at all - return all users; 4. Specify an identity to only return a single mailbox.  Now, that's nice that these filters exist, and they are pretty easy to use.  You can reference the help for Get-Mailbox for more details (get-help get-mailbox -full).  However, what if you only want to move a handful of mailboxes?  You need to do some more work.

First, you'll need to define an array by specifying a variable.  You also need to know the alias of the users that you are wanting to move.

$mboxes = "user1","user2","user3","user4"

You have now successfully created an array.  Now, you can perform an action on that array using the Foreach command.  The basic usage of the foreach command is as follows.

foreach ($<item> in $<collection>) {<command_block>}

One thing to remember is that $<item> also references a variable, but it is dynamically created, and you can call it whatever you want.  In our case, the resulting command would look something like this.  I've chosen to use $mb for the$<item> variable.  We'll start out by simply getting the mailbox information for those users to make sure it works, then we'll move on to the more complex move portion.

Note that unless your current account has rights in both forests, you will still need to pass the -credential string, and you will need to define a variable for the credentials using get-credential.  To make things easier, I always use $s for the Source Forest credentials, and $t for the Target Forest credentials.

foreach ($mb in $mboxes) {get-mailbox $mb -DomainController <source DC FQDN> -Credential $s}

You should now have a list on your screen that looks something like this.

Now that we are sure that the results are being returned properly, let's include the move-mailbox command.  First, I'll show you what doesn't work.

foreach ($mb in $mboxes) {get-mailbox $mb -DomainController <source DC FQDN> -Credential $s} | move-mailbox -TargetDatabase "Server\Storage Group\Database" -GlobalCatalog <target GC FQDN> -SourceForestCredential $s -SourceForestGlobalCatalog <source GC FQDN> -TargetForestCredential $t -AllowMerge -SourceMailboxCleanupOptions deletesourcemailbox

You might think this would work, because previous experience with Powershell has taught you about Pipelining, but it will return an error indicating you have an empty pipe element, which is not permitted.  In order to get this to work, you actually have to include the Pipeline within the command block.  I'm going to move the end brace } to the end of the statement.

foreach ($mb in $mboxes) {get-mailbox $mb -DomainController <source DC FQDN> -Credential $s | move-mailbox -TargetDatabase "Server\Storage Group\Database" -GlobalCatalog <target GC FQDN> -SourceForestCredential $s -SourceForestGlobalCatalog <source GC FQDN> -TargetForestCredential $t -AllowMerge -SourceMailboxCleanupOptions deletesourcemailbox}

The above command will loop through each user in your array, and perform the move-mailbox command.  You should note that the command I used assumes that the user account has already been migrated to the target domain by using a migration tool such as the Active Directory Migration Tool, and that you have migrated SID History (The SID is used to match the source mailbox to a target account).  The other option would be to include the -NTAccountOU parameter, and have Exchange 2007 create a disabled user account, but this is much less desirable, as it ends up creating a linked mailbox instead of a normal user account.

[update]
Thanks to comments from some of you, who pointed out that using foreach, while it *does* work as it is shown above, it isn't optimal because it passes the results serially.  In other words, it means that it will pass the first result to move-mailbox, then it will wait to pass the next result until the first loop completes.  This will result in move-mailbox being called 4 times (for the example above), more if you have a larger list.  It also doesn't take advantage of the multi-threading capability of move-mailbox.

In order to make it work properly, you can either simply specify the array, or you can pass the array into the foreach loop (instead of specifying each item in the array).  Examples below.

$mboxes | get-mailbox $mb -DomainController <source DC FQDN> -Credential $s | move-mailbox -TargetDatabase "Server\Storage Group\Database" -GlobalCatalog <target GC FQDN> -SourceForestCredential $s -SourceForestGlobalCatalog <source GC FQDN> -TargetForestCredential $t -AllowMerge -SourceMailboxCleanupOptions deletesourcemailbox

foreach { $mboxes } | get-mailbox $mb -DomainController <source DC FQDN> -Credential $s | move-mailbox -TargetDatabase "Server\Storage Group\Database" -GlobalCatalog <target GC FQDN> -SourceForestCredential $s -SourceForestGlobalCatalog <source GC FQDN> -TargetForestCredential $t -AllowMerge -SourceMailboxCleanupOptions deletesourcemailbox

What I'm learning here is that there is a LOT to learn about Powershell!!!

Thanks to Devin Ganger for pointing out the limitation, and thanks to Evan Dodds for helping with the correct usage.  I'll be posting a followup to this with some more information on moving mailboxes using a csv file, and using other filters to get the list you want.

As you no doubt know by now, Exchange 2007 introduces different types of clustering.  It still retains the traditional Single Copy cluster where all data is stored in a central location (i.e. SAN).  It also introduces the concept of Cluster Continuous Replication, or CCR, where centralized storage is not required, rather each server contains a separate copy of the data.  This is achieved by an initial "seeding", and is then maintained by replication of log files.  Service Pack 1 for Exchange 2007 includes yet a third type of cluster a new technology for managing server failures, called Standby Continuous Replication, or SCR, but we'll leave that for another post.

[edit] as was pointed out to me, SCR isn't actually a clustered solution, as it does not use Windows clustering.  I've thus modified the original post to reflect that.  However, it can be used as the target for an Exchange 2007 cluster.  More details to come when I post about SCR.

For today, I've installed a new CCR cluster, but I didn't allow it to complete.  Let's have a look at the setup log.  This is located in the c:\ExchangeSetupLogs directory.  The one that contains the most information is ExchangeSetup.log.  Since this log file contains a lot of information, I'll only post part of it.

[8/3/2007 4:46:12 PM] [0] Starting Microsoft Exchange 2007 Setup
[8/3/2007 4:46:12 PM] [0] **********************************************
[8/3/2007 4:46:12 PM] [0] Setup version: 8.0.685.24.
[8/3/2007 4:46:12 PM] [0] Logged on user: E12CCR\Administrator.
[8/3/2007 4:46:12 PM] [0] Command Line Parameter Name='mode', Value='Install'.
[8/3/2007 4:46:12 PM] [0] Command Line Parameter Name='sourcedir', Value='D:\i386'.
[8/3/2007 4:46:12 PM] [0] Command Line Parameter Name='fromsetup', Value=''.
[8/3/2007 4:46:12 PM] [0] ExSetupUI was started with the following command: '-mode:install -sourcedir:D:\i386 /FromSetup'.
[8/3/2007 4:46:17 PM] [0] Setup is choosing the domain controller to use
[8/3/2007 4:46:18 PM] [0] Setup is choosing a local domain controller...
[8/3/2007 4:46:20 PM] [0] Setup has chosen the local domain controller e12dc.E12CCR.com for initial queries
[8/3/2007 4:46:21 PM] [0] PrepareAD has been run, and has replicated to this domain controller; so setup will use e12dc.E12CCR.com
[8/3/2007 4:46:21 PM] [0] Setup is choosing a global catalog...
[8/3/2007 4:46:21 PM] [0] Setup has chosen the global catalog server e12dc.E12CCR.com.
[8/3/2007 4:46:21 PM] [0] Setup will use the domain controller 'e12dc.E12CCR.com'.
[8/3/2007 4:46:21 PM] [0] Setup will use the global catalog 'e12dc.E12CCR.com'.
[8/3/2007 4:46:21 PM] [0] Exchange configuration container for the organization is 'CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12CCR,DC=com'.
[8/3/2007 4:46:21 PM] [0] Exchange organization container for the organization is 'CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12CCR,DC=com'.
[8/3/2007 4:46:21 PM] [0] This machine is part of a Windows failover cluster.
[8/3/2007 4:46:21 PM] [0] This server is not an active node for any Clustered Mailbox servers.
[8/3/2007 4:46:21 PM] [0] Setup will search for an Exchange Server object for the local machine with name 'E12CCR2-N1'.
[8/3/2007 4:46:21 PM] [0] No Exchange Server with identity 'E12CCR2-N1' was found.
[8/3/2007 4:46:36 PM] [0] The following roles are unpacked:
[8/3/2007 4:46:36 PM] [0] The following roles are installed:
[8/3/2007 4:46:36 PM] [0] The local server does not have any Exchange files installed.
[8/3/2007 4:46:36 PM] [0] Setup will use the path 'D:\i386' for installing Exchange.
[8/3/2007 4:46:36 PM] [0] The server is cluster type: 'None'.
[8/3/2007 4:46:36 PM] [0] The requested cluster type: 'None'.
[8/3/2007 4:46:36 PM] [0] The installation mode is set to: 'Install'.
[8/3/2007 4:46:36 PM] [0] An Exchange organization with name 'First Organization' was found in this forest.
[8/3/2007 4:46:36 PM] [0] Active Directory Initialization status : 'True'.
[8/3/2007 4:46:36 PM] [0] Schema Update Required Status : 'False'.
[8/3/2007 4:46:36 PM] [0] Organization Configuration Update Required Status : 'False'.
[8/3/2007 4:46:36 PM] [0] Domain Configuration Update Required Status : 'False'.
[8/3/2007 4:46:37 PM] [0] Applying default role selection state

This simply shows an overview of the setup choices that have been made.

[8/3/2007 4:52:39 PM] [1] Setup launched task 'test-setuphealth -DomainController 'e12dc.E12CCR.com' -DownloadConfigurationUpdates $false -ExchangeVersion '8.0.685.24' -Roles 'ClusterMailbox' -ScanType 'PrecheckInstall' -SetupRoles 'AdminTools','Mailbox','ClusterMailbox' -CmsName 'CCR-EVS2' -CmsDataPath 'E:\Exchsrvr\MDBData' -CmsIPAddress '10.10.201.230' -CmsSharedStorage $false -CreatePublicDB $false'

This is showing the pre-requisite check tests that are being performed, and shows that the setup roles that have been selected are AdminTools, Mailbox, ClusterMailbox.  Most of the rest of the log file just shows the progress of each role, so I won't bore you with that.  Let's get on to the interesting part.  Once the mailbox role finishes installing, setup runs the new-ClusteredMailboxServer to create the actual cluster.  One nice thing is that you don't have to worry about creating the Exchange group in Cluster Admin as you had to do with Exchange 2003.  Setup now creates it for you automatically.  Ok - here is the failure.  Note the section in Bold.

[8/6/2007 5:36:17 PM] [1] Processing component 'Mailbox System Attendant Dependent Tasks' (Configuring tasks dependent on System Attendant service).
[8/6/2007 5:36:17 PM] [1] Executing 'start-ClusteredMailboxServer -Identity:$RoleName', handleError = False
[8/6/2007 5:36:17 PM] [2] Launching sub-task '$error.Clear(); start-ClusteredMailboxServer -Identity:$RoleName'.
[8/6/2007 5:36:18 PM] [2] Beginning processing.
[8/6/2007 5:36:18 PM] [2] Administrator Active Directory session settings are: View Entire Forest: 'True', Configuration Domain Controller: 'e12dc.E12CCR.com', Preferred Global Catalog: 'e12dc.E12CCR.com', Preferred Domain Controllers: '{ e12dc.E12CCR.com }'
[8/6/2007 5:36:18 PM] [2] Searching objects "ccr-evs2" of type "Server" under the root "$null".
[8/6/2007 5:36:18 PM] [2] Previous operation run on domain controller 'e12dc.E12CCR.com'.
[8/6/2007 5:36:18 PM] [2] Start-ClusteredMailboxServer is trying to start clustered mailbox server ccr-evs2.
[8/6/2007 5:37:05 PM] [2] Start-ClusteredMailboxServer finished starting (bringing online) clustered mailbox server ccr-evs2.
[8/6/2007 5:37:05 PM] [2] [ERROR] Unexpected Error
[8/6/2007 5:37:05 PM] [2] [ERROR] Clustered mailbox server 'ccr-evs2' is not in a started (online) state (Failed). The cluster resource 'First Storage Group/Mailbox Database (ccr-evs2)' is in state (Failed).
[8/6/2007 5:37:05 PM] [2] Ending processing.
[8/6/2007 5:37:05 PM] [1] The following 1 error(s) occurred during task execution:
[8/6/2007 5:37:05 PM] [1] 0. ErrorRecord: Clustered mailbox server 'ccr-evs2' is not in a started (online) state (Failed). The cluster resource 'First Storage Group/Mailbox Database (ccr-evs2)' is in state (Failed).
[8/6/2007 5:37:05 PM] [1] 0. ErrorRecord: Microsoft.Exchange.Management.Tasks.NewCmsNotOnline: Clustered mailbox server 'ccr-evs2' is not in a started (online) state (Failed). The cluster resource 'First Storage Group/Mailbox Database (ccr-evs2)' is in state (Failed).
[8/6/2007 5:37:05 PM] [1] [ERROR] Clustered mailbox server 'ccr-evs2' is not in a started (online) state (Failed). The cluster resource 'First Storage Group/Mailbox Database (ccr-evs2)' is in state (Failed).
[8/6/2007 5:37:05 PM] [1] Setup is halting task execution because of one or more errors in a critical task.
[8/6/2007 5:37:05 PM] [1] Finished executing component tasks.
[8/6/2007 5:37:05 PM] [1] Ending processing.
[8/6/2007 5:40:48 PM] [0] End of Setup

The Setup UI will now show that setup has completed with an error.  Ok, so let's re-run setup to allow it to complete.  What's that?  The Setup UI only allows you to Add or Remove roles.  Oh yeah - since this was set up as a Cluster, you can't have any other roles on it, and you can't de-select the Active Cluster role.  Now at this point, I can actually go in to Cluster Admin, and verify that all the resources are online.  In the above case where my First Storage Group/Mailbox Databases (ccr-evs2) was in a failed state, I simply brought it online, and it came online just fine.  Since all the resources are online, you might think that everything is hunky dory.  Not so, my friend.  We've got a BIG problem.  The System Attendant Object was never fully provisioned.  If you leave your cluster running in the above state, you'll see lots of issues related to many tasks that the System Attendant Mailbox is used for.  In my above setup, if we look at the System Attendant object using ADSIEdit, we will find that there are no proxy addresses (BAD BAD BAD), and msExchPoliciesIncluded is not set.  This will cause massive problems with Free/Busy, and you'll see NDR's being generated for any messages sent to your System Attendant mailbox (duh - it doesn't have an e-mail address)

OK - so how do you fix it?  Well, before we get there, there is one more thing you need to look at that will tell you if setup encountered any problems that need to be fixed.  Open up the registry, and navigate to

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\v8.0

and see which subkeys exist.  You should see a separate key for Each role that is installed.  For the above cluster, if setup had completed successfully, you would only see the following keys.

v8.0
   AdminTools
   MailboxRole
   Setup

In my case, however, I saw one more (bolded)

v8.0
   AdminTools
   ClusteredMailboxServer
   MailboxRole
   Setup

Viewing that key showed a Value with a name of "WaterMark" that contained a hex string.  This Watermark is very important!  It is how setup notes where it left off, and what still needs to be completed.

Ok - now on to the resolution.  If you experience a failure during setup (clustered or not), the best way to resolve it in almost all cases is to run setup from the command prompt.  The command-line version of setup is called from setup.com.  For my cluster issue, since the Mailbox role completed, I don't have to actually run setup and select a role to install, rather I need to re-setup the cluster.  The command I used was

setup.com /newcms /cmsname:ccr-evs2 /cmsipaddress:10.10.21.230 /cmsdatapath:e:\exchsrvr\mdbdata

When this command is run on an existing cluster with this same name, all setup will do is determine if there are any actions that have not been completed.  In other words, it checks for a Watermark.  In my case, it picked up at about 75% or so, and ran through to completion successfully.  Inspecting the setup log after completion shows the following tasks (which I'd consider fairly important!)

[8/6/2007 5:51:55 PM] [1] Executing 'enable-SystemAttendantMailbox -Identity:$RoleFqdnOrName -DomainController $RoleDomainController', handleError = True
[8/6/2007 5:51:55 PM] [2] Launching sub-task '$error.Clear(); enable-SystemAttendantMailbox -Identity:$RoleFqdnOrName -DomainController $RoleDomainController'.
[8/6/2007 5:51:55 PM] [2] Beginning processing.
[8/6/2007 5:51:55 PM] [2] Searching objects "ccr-evs2" of type "ADSystemAttendantMailbox" under the root "First Organization".
[8/6/2007 5:51:55 PM] [2] Previous operation run on domain controller 'e12dc.E12CCR.com'.
[8/6/2007 5:51:55 PM] [2] Processing object "Microsoft System Attendant".
[8/6/2007 5:51:55 PM] [2] Applying RUS policy to the given recipient "Microsoft System Attendant" with the home domain controller "e12dc.E12CCR.com".
[8/6/2007 5:52:17 PM] [2] The RUS server that will apply policies on the specified recipient is "CCR-EVS2.E12CCR.com".
[8/6/2007 5:52:17 PM] [2] Saving object "Microsoft System Attendant" of type "ADSystemAttendantMailbox" and state "Changed".
[8/6/2007 5:52:17 PM] [2] Previous operation run on domain controller 'e12dc.E12CCR.com'.
[8/6/2007 5:52:17 PM] [2] Ending processing.

If you aren't installing a cluster, you may still see a Watermark value for one of the other roles (ClientAccess, HubTransport, Mailbox, UnifiedMessaging, etc.

If you have a watermark for one of those roles, you need to note which role has a watermark, then run the following

setup.com /roles:mb (or insert the name of the role that shows the watermark)

This will allow setup to process that role, and based on the watermark in the registry, it will continue where it left off.  Once setup completes successfully, the watermark value will be removed.

I'm hoping and expecting that Service Pack 1 for Exchange 2007 will be able to handle issues like this one much better, as it should include a "Reinstall" option.  If not, you can always fall back to the trusty command-line options.

Sorry folks.  I'm starting to see some spam comments with nasty stuff in them.  As of now, if you want to leave a comment here, you can no longer do so anonymously.

These guys are hilarious!  I first caught on to them when they blended an iPhone (LOL!).  Of course the funniest videos are the "Don't Try this @ Home" series.  The latest in the series has them blend 6 Bic lighters.  Do you think they end up exploding?  Watch and see.  They have even syndicated the videos as an RSS feed, so you can keep up to date.

I wonder how much business the videos have generated for them.  I can remember links to the iPhone video showing up all over the place.  Viral marketing at it's best, I suppose.  Have fun and look at some of the other stuff they blend while you're there.

Link to Will It Blend? 6 Bic lighters

Have you noticed that there are a lot more things that you need to do (or can do) via the Command Shell in Exchange 2007?  Do you wish that you could automatically save the session information to a text file?  Here's a great tip help you out with that.

First, a couple things.  In order to automate saving this information, you need to modify your PowerShell Profile.  If you aren't sure where your profile resides, at the command shell, simply type

[PS] C:\>$profile

This will return your profile information.  By default, it should be stored in the C:\Documents and Settings\<user>\My Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1.  However, if you look in that location, odds are you won't find anything.  That's because although the profile variable is automatically set, the profile itself won't be created by default.  No problem - just create the directory and the file.

Next, let's look at the command to record your session information.  You may have seen this in one of the "Tip of the day" little tidbits that come up each time you launch the Exchange Management Shell.  If not, the command you use is

[PS] C:\>Start-Transcript <filename>

This will begin recording your session information to the file that you specify.

I don't like having to do that each time, though.  Let's make this more automated.  By that, I mean let's modify your profile.

Editing of your profile is just done with Notepad, which is the default editor for .ps1 files.  Oh yeah, by the way, you probably noticed that a .ps1 file doesn't automatically launch powershell, like a .bat file would launch a command prompt.  This is for security reasons.  This way, if you download a .ps1 file from somewhere and it contains malicous code, you can't simply double-click on it.

OK - back to the task at hand.  Once you have your profile open, we're going to add the following lines.

CD \ *Note - there is a space between the CD and the \*
$date = get-date -UFormat %m_%d_%y
Start-Transcript c:\pslogs\$date.txt -append -noclobber

This will set the working directory to the root of the C drive (gives you more real estate to work with), defines a variable called $date, and specifies that it will get the date in the format of Month_Day_Year (i.e. 07_24_07), then tells Powershell to start the transcript each time it is launched, and it uses the variable we defined earlier to automatically create a new text file based on the current date.  Additionally, since the default behavior of start-transcript is to overwrite the previous file, we are telling it to append to an existing file (if present), and the -noclobber tells it to not overwrite the previous file.

Powershell does have some other options here.  The Start-Transcript command includes a -Path parameter that you can define, but I like the way that the above works.

Do you have any helpful Powershell tricks or tips?  I'd love to hear from you.

[edit]
After further testing, it looks like when Powershell was starting, it didn't like the $date variable for the directory name.  I've edited the line you add to your profile to reflect this.  What I've changed it to is to set the file name with the $date variable, which seems to work fine.

As some of you may be aware, the behavior when dealing with disabled user accounts has changed.  Prior to these changes, when you disabled a user account, any mail sent to that account would NDR, and accessing the mailbox was not possible.  In addition, you would see many 9548 warnings logged in the Application log for each mailbox-enabled user that had been disabed.  The text of the 9548 message would look like this:

Event ID : 9548
Raw Event ID : 9548
Category : General
Source : MSExchangeIS
Type : Warning
Generated : <date>
Written : <date>
Machine : SERVERNAME
Message : Disabled user /o=<Organization>/ou=<Administrative Group>/cn=Recipients/cn=UserName does not have a master account SID. Please use Active Directory MMC to set an active account as this user's master account.

Each mailbox-enabled user account has an attribute called msExchMasterAccountSID.  This is important, because when Exchange receives an e-mail message for a recipient, the Simple Mail Transfer Protocol (SMTP) address is translated to a SID. Active Directory searches for an object that has an entry in the proxyAddresses attribute that matches the SMTP address. When an entry is found, Exchange tries to determine the active SID for the user account. If the user account is disabled and if the msExchMasterAccountSid attribute is not set, Exchange cannot determine an active SID. Exchange then logs a warning event 9548, and the message is returned as undeliverable.  In the past, tools such as NoMAS (written by Alex Seigler) could be used to correct this issue, as it would bulk search for accounts with incorrect settings (such as disabled accounts with msExchMasterAccountSID not set), and would then fix them.  This could also be fixed manually by either re-adding the SELF account on the mailbox permissions, or by adding another account, and specifying it was the "Associated External Account".

This behavior was changed in Exchange 2003 via a hotfix.  In Exchange 2003 SP2, builds of store.exe 6.5.7651.14 and greater incorporate the change, and with Sp1, builds of store.exe 6.5.7234.3 and greater incorporate this change.  The corresponding KB articles are 916783 (2003 SP2) and 903158 (2003 SP1).  The new behavior of Exchange is that if the SELF SID is missing from the Mailbox permissions, store.exe checks to see if the msExchMasterAccountSID is populated (this is the same as before).  If it is not populated, then store.exe will use the objectSID of the user account, which should always be present.

What does this mean for you?  Well, for one thing, it means that you should no longer see 9548 messages logged.  Since Exchange now goes on to use the objectSID if no msExchMasterAccountSID is detected for a disabled account, this also means that unless you take additional action, disabled accounts will now continue to receive e-mail.  For some companies, this is good.  Others may not like it as much.  If you happen to fall into the second camp, below you will find a few workarounds that will allow disabled accounts to once again generate NDRs, though it won't be the exact same NDR message as before.

To force a disabled account to stop receiving emails and instead, generate a Non-Delivery Receipt (NDR)to the sender, take the following actions:

Option 1:

Set Delivery Restrictions to only allow certain users to send messages to the disabled account.

1. Open Active Directory Users and Computers and navigate to the disabled account object. 
2. Right click on the account object and select Properties. 
3. Click on the Exchange General tab and then click on the Delivery Restrictions button. 
4. On the Delivery Restrictions property window, select "Only From" under "Message Restrictions" and do either of the following:
• Add the user account itself to this list.
• Create a dummy account that no one will use and add it to the list.
5. Wait for AD Replication or Force AD Replication. Test sending mail to disbled user, you should get NDR as expected.

Logic here: Messages will be received on this account "ONLY FROM" the dummy account/the user itself.  Everyone else will receive an NDR as expected, though the actual NDR that is generated will be one for delivery restrictions (i.e. you don't have access to send to this person).

Option 2:

If Receiving message Size (Max) is set to Zero (0 KB), the sending user will get an NDR (Though the reason of NDR would be different).

To modify this option, go to the following location:
AD User properties=>Exchange General=> Delivery Restrictions=>Receiving Message Size=>Maximum KB = 0

Note: Options 1 and 2 should be able to be set in bulk by using either an import file (LDIFDE), or by using a tool such as ADModify, but they would need to be run each time another account is disabled.

Option 3:

If you set the size limit of mailbox as 0KB, you will receive an NDR (Though reason of NDR would be different)

To modify this option, go to AD User Properties=>Exchange General=> Storage limits=> Prohibit send and receive at (KB): 0

Note: Option 3 can be implemented using an Exchange System Policy.  Simply create a new System Policy, define the Send/Receive limits, and then apply that System Policy to a Mailbox Store. Once the account is disabled, you would simply move the mailbox to the Mailbox Store managed by the policy, and the Send/Receive limit will automatically be enforced.

If a System Policy is used, it may also be desirable to not send warning messages to those mailboxes. This can be accomplished using the same policy, and setting the warning message interval to custom, and deselecting all time periods.

Option 4:

Remove the SMTP addresses from the disabled account.  This will result in an NDR being generated as the destination address will not exist.

Note: The Primary SMTP Address for a user account *cannot* be removed by using Active Directory Users and Computers.  The interface will not allow it to be removed.  If you choose this option, you would have to use another editing tool, such as ADSIEdit (available in the Windows Support Tools), or perhaps something such as ADMofity.

While none of these workarounds provide the same exact functionality the existed prior to this change, they are nonetheless valid workarounds.  The third option appears to be the easiest to implement in my opinion, but in today's world, it is all about choice.

So you want to add a new Exchange administrator and set the scope to multiple servers, but the management shell won't allow you to do this?

Here is what happens.

Add-ExchangeAdministrator -identity <user> -role ServerAdmin -scope "server1","server2"

Error: Add-ExchangeAdministrator : cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'Scope'. Specified method is not supported.

Here's the solution.

First, you need to build an array that contains the servers in question.

[PS] C:\>$ExServers = "Server1","Server2","Server3"

[PS] C:\> foreach ($server in $exservers) { Add-ExchangeAdministrator -identity <user> -role ServerAdmin -scope $server }

Now the result is a success, and you will see the appropriate message indicating that the user has been added, and that to fully administer the Exchange server, you should add the user to the local admins group on the server.

Running Get-ExchangeAdministrator will also now show this user in the list with a separate entry for each server.

Now, one more note here.  Remember that arrays are only maintained for your specific powershell session.  As soon as you close Powershell, you will lose any defined arrays (or variables) unless you have taken actions (for example, modified your powershell profile) to include them.

I've seen a few of these reports recently and worked on one personally, so I thought I would mention this in case anyone else has run into this issue and wasn't sure how to fix it.

The environment:
ISA server 200x using a Web Publishing Rule to publish OWA on an Exchange 2003 server.

The problem:
When using OWA externally, files larger than 50kb cannot be attached.  The symptom is that the attachment screen will simply go blank.  If you wait long enough, you may eventually see a timeout error, but that could be a long time (30 minutes or more).  Attaching the same file from inside the network works fine.

The apparent solution:
On the Exchange 2003 server, there is a setting within the IIS metabase that needs to be modified.  Specifically, the parameter UploadReadAheadSize needs to be set.

Why does this need to be changed?

I don't know.  I'm not an ISA expert, nor am I am IIS expert.  The above-mentioned parameter is not set by default, and IIS will use the default schema value of 49152 bytes (48kb).  It is worth noting that this parameter apparently does not *always* need to be modified.  You should thus only modify this attribute if you are encountering this issue.

This parameter can be modified using adsutil.vbs, which is included by default with IIS, and exists in the inetpub\adminscripts directory.  It can also be modified by editing the metabase.xml file in the \winnt\system32\inetsrv directory.

First, verify that no value is set.

C:\inetpub\adminscripts>adsutil get w3svc/UploadReadAheadSize

You should get back a response

The parameter "UploadReadAheadSize" is not set at this node.

To modify this parameter, run the following command

C:\inetpub\adminscripts>adsutil set w3svc/UploadReadAheadSize "<Size in bytes>"

For example, if you want to change this value to 20mb, you would put in "20000000" as the size.

The response should be

UploadReadAheadSize               : (INTEGER) 20000000

Once you make this change, it should be effective immediately.

Now that you have been working with Exchange 2007 for a while, you may notice that in the Exchange Management Console, there are a few new things that you see.  One of these is that when you look at objects, you now see a column labeled Recipient Type Details.  This is, in fact, a new attribute that has been added for Exchange 2007.  There is another attribute called Recipient Display Type.  You will not see them with this name in AD, however.  The mapping is as follows:

Recipient Display Type = msExchRecipientDisplayType
Recipient Type Details = msExchRecipientTypeDetails

These two attributes are new attributes that are added to the Active Directory Schema during Exchange 2007 setup. They are used in determining the type of recipient in the Address Book. They are displayed in the Exchange Management Console under Recipient Configuration, and in Exchange Management Shell if you perform a get- command and instruct the shell to return the full list (i.e. Get-Mailbox | fl )

Like many other Active Directory Attributes, these are represented by Integer Values in Active Directory.  One important item to note here is that you do not want to be arbitrarily changing these values.  The Recipient Display Type is something that should only be set by Exchange.  Changing it via any other method is not supported.

I've included a couple of tables for reference.  The first table covers the different values that can be assigned to the Recipient Display Type attribute.

This second table is perhaps of more interest.  In most situations, you will see objects appear as they should.  For example, a new mailbox (for an existing user or a new user) should always show up as a User Mailbox.  If your Exchange 2007 server co-exists with Exchange 2003 or Exchange 2000 servers, then all mailboxes on those 2000 or 2003 servers will show up as Legacy mailboxes.  You may, however, find under certain circumstances that it does not appear correctly.  For instance, after moving a mailbox from an Exchange 2003 server, which appears as Legacy Mailbox, to your Exchange 2007 server, it may now appear as a Linked Mailbox.  If this happens, you need to investiage why.  One possible cause could be if Associated External Account was set on the 2003 mailbox.

Also note that this attribute will not always be stamped with a value.  For example, Groups do not appear to have this attribute set with a value.  This leads me to conclude that Exchange is able to read this information from other attribute values as well (such as perhaps the GroupType attribute).

Although you should not be changing these values in a production environment, it is always fun to play around in a lab and learn more about what they do.  But make sure you do your playing in a lab environment!

[Update]
Although I couldn't find it previously, some of this information is documented in the Technet Exchange 2007 documentation.  If you happen to be experiencing an issue where a mailbox is showing up with the wrong Recipient Display Type, please reference the following links for details on how to correct that.  Also note that in most cases, there is a reason for a mailbox showing up the way it is.  For example, if you perform a cross-org mailbox move without first migrating the user account, it will show up as a Linked mailbox, and that is normal.  What you don't want to do is simply modify this value without addressing the other reasons for the current value being stamped.

http://technet.microsoft.com/en-us/library/bb201749.aspx - How to Convert a mailbox
http://technet.microsoft.com/en-us/library/bb201694.aspx - How to Convert a mailbox to a Linked mailbox

[thanks to the comment of a visitor, it looks like I was off in my decimal conversions.  I've edited the top table accordingly]

After enduring the many smart-alecky TV commercials that Apple has produced (some are funny, I grant), someone has written up a  cartoony comparison of the I-Phone vs a WM SmartPhone.

Having worked with Windows Mobile devices for a good long while now, I found this pretty amusing.  No doubt the Apple faithful will be unduly offended by this, as already indicated in some of the comments, but hey - "IT'S A PARODY!  CHILL OUT!"

Anyways - check out the link below.

Link to Hi I’m an iPhone. And I’m a Smartphone. - istartedsomething