Why the compulsion to jump to 64 bits?

Teaching (and attending) classes virtually has many advantages, yet occasionally there are quirks. Some of my students recently asked for a longer break in our session than I had suggested because they had only two elevators in their building. Just as you could get into traffic jams in the elevator, on the freeway, or on the way past your friendly neighborhood farm, so too could your servers run into traffic jams – several kinds actually.

I’m not going to focus on networking, disk transfer rates, or other such peripheral sorts of traffic jams, but at the heart of computing – in the CPUs, the processor cores. A question I am often asked is “Why do we need 64-bit servers?” Don’t worry, the answer here won’t be too terribly technical.

With Microsoft operating systems and services, there has been a trend brewing. Exchange Server 2007 is available for x64 servers in production, and only available for evaluation purposes on x86 (32-bit) architectures. Exchange 2010 is x64 only, which should come as no surprise. Windows Server 2008 can be hosted by x86 or x64 hardware, yet Windows Server 2008 R2 runs only on x64 (and Itanium/EPIC (IA-64), another 64-bit architecture) but not x86. Various SQL Server 2005 and 2008 editions are available for x86, x64, and IA-64.

On the client side, Windows 7 is still available for x86 as well as x64. But for computers in both the client and server roles, is 64-bit computing really necessary or desirable? To a degree, the question is nearly moot for mainstream computing, because although lovely 8-bit and 16-bit systems still exist in embedded devices, mainstream computing is being swept along by a tidal wave. Just as desktops, portables, and servers mostly migrated from 16-bit to 32-bit processors years ago, the move to 32-bit to 64-bit systems is considered by many people to be inevitable.

But is it better? That’s debatable. It really depends on what you’re doing. To better answer the question, here are some fundamental questions you could ask about the software you’re running.

  1. Are the integers used in your software within the range ±4 billion? In other words, are you using 32-bit integers? Or do you need a greater range of values?
  2. Do you use floating point (real) numbers extensively which could benefit from faster 64-bit and 128-bit processing?
  3. How are character strings processed? Are you using Unicode characters?
  4. Do you need to address more than 4 billion bytes of memory per process? Actually, within a 4GB virtual memory space, only 2GB or 3GB may be available to a given process.
  5. Do you need to address far more than 4GB, perhaps more than 16GB of physical memory (RAM)?

From an end-user or even from an administrator or systems engineer perspective, the answers to these questions may not be entirely obvious. Nor should this list of questions be construed as anything near complete with respect to criteria for ascertaining 32-bit versus 64-bit tradeoffs. Certainly, we have specified no scientific algorithm or heuristic herein. The point here is that the answers to these questions are contributing factors yet the real assessment is fairly complex.

Much software runs perfectly fine on 32-bit systems. If you’re doing high-end audio processing, or certainly processing video, or hosting large databases, then 64-bit systems can have a marked, measurable capability and performance advantage over 32-bit systems. Before you start asking when 128-bit systems will become mainstream, you should be carefully planning your migration path to 64-bit workstations and servers if you haven’t already gone through that evolution process.

With respect to Windows, Mac OS X, Linux, Solaris, and other operating systems, the choice is being made based on what the masses need. If your organization doesn’t even have or need an elevator, that doesn’t mean you can or ought to stick with 32-bit computing forever.

Rose, revisited

Picture 17


A while back, we looked at random name generation in Rose, by any random name… and I had an error in both forms of the script code there. Over at the Global Knowledge blog on Microsoft, the More on PowerShell post had the same error. Luckily, Eyal Peleg replied there that the value of $percentFemale=1 would result in all males rather than all females! So please either go over to the GKonMicrosoft blog and read my reply there, or… here’s the summary here.

Indeed! Thanks for noting that – sorry for the error.
Yes, to correct this we should certainly reverse this.
In the first form shown this should be:
if( $rand.NextDouble() -lt $percentFemale ){
$gender = “female”
$gender = “male”

And in the more “dense” PowerShell 2.0 form shown later, the correction would be:
$f = (Invoke-Expression (“`$_RN_{0}[`$rand.Next(`$_RN_{0}.Count)]” -f $(if( $rand.NextDouble() -lt $percentFemale ){“female”}else{“male”}))).Split(“`t”)[0].ToLower()

Again, thanks Eyal for pointing this out.

Email is a Privilege, Not a Right… or is it?

We hold these truths to be self-evident, that all users are endowed with certain unalienable rights, such as open copyable, forwardable, printable, free email? No, I just skimmed the Declaration of Independence of the United States of America, and I don’t believe that in any nation, email is a right. Whether you believe email to be a blessing, a curse, or something in between, would you agree that some communications, some messages, ought to be freely redistributable and usable for all time, yet others… yes, certain other messages should be… protected?

A certain change is afoot – a change in the landscape of email which changes many long-assumed-immutable rules. Once upon a time, access to a file system was governed by permissions such as read, write, and execute. These still exist, yet Windows evolved out of the RWXDPO permission model to the more fine-grained {R,ra,re,rp,W,ac,wa,we,X,D,ds,P,O,sy}  permissions several years ago with Windows 2000 for files and folders in the NTFS file system. The Windows registry, services, printers, Active Directory Domain Services, and other subsystems have their own similar but distinct permissions.  Classically, if you had Read access to a file, it meant that you could copy, print, view, resave, forward, reply, resend, transfer, and do other amazing things with that file. In fact, resaving a copy of the file would give you read-writable copy of the file which you could sent to other people.

Is email always destined to dwell in the land of chaos? Well, facilities such as PGP and S/MIME can help with authentication and encryption for confidentiality, and Exchange Server and Outlook have supported S/MIME for several versions (e.g. 2003, 2007, 2010). But the change that’s afoot more recently is facilitated by Windows Server 2008 (R1 and R2) Active Directory Rights Management Services (AD RMS). Yes, that’s the same AD RMS that lets Microsoft Office 2007 applications such as Word take .doc files beyond the abyss of the RWXD model’s read-allows-anything motif.

Now, Exchange Server 2010 and Outlook 2010 allow AD RMS-based integration to provide services well beyond S/MIME. Now, before you hit that Send button to deliver a message to your colleagues, customers, friends, et cetera, perhaps you don’t need to be quite as concerned as to how long all of those recipients will keep the message, who they might forward it to, where they might copy and paste it, who their email administrators might be, why hackers have gotten into their networks and computers, and so on. No need to worry. Well, maybe. How can AD RMS really provide Information Rights Management (IRM) to users of Exchange 2010 and Outlook 2010?

First, note that now only can native Outlook 2010 clients benefit from this, but Exchange 2010’s Outlook Web App (OWA, formerly known as Outlook Web Access in earlier Exchange) clients can also benefit. Better still, this is policy driven in a well-thought-out way so that there’s even a back-door for journaling, and yet ensure that we have protection where we need it with both client and transport coverage. What does this all mean?

If you send an email to five people with View-Only access, only those five people can view it. Aside from doing screen shots or video recording, those five people cannot print or transfer the message contents.  No forwarding or reply-all. View only. Plus you can specify that the message is viewable for a limited time only. After 15 days, the viewable nature of the message can vanish as well, after an expiration date. This sort of policy or individual message setting could apply to voicemail too. Like digital rights management in general, this email style Information Rights Management (IRM) changes the landscape of messaging. And that’s good when people are blogging that 92% of email is spam and that Facebook may spell an end for email as we know it. Or knew it. It’s a dynamic game. Don’t stand still. Evolve.

For more information on Exchange 2010’s IRM capabilities, see the “IRM-Protected E-Mail Functionality with Active Directory Rights Management Services” topic at TechNet’s “What’s New in Exchange 2010” topic. Here’s a quote from that topic at Microsoft TechNet.

“The following is a list of new Information Rights Management (IRM)-protected e-mail functionality with Active Directory Rights Management Services (AD RMS) included in Exchange 2010:

  • Microsoft Outlook protection rules, to apply IRM-protection to messages in Outlook 2010
  • Transport protection rules, to apply IRM protection to messages based on rule conditions
  • Persistent protection of attachments in IRM-protected messages
  • Support for AD RMS templates
  • Support for IRM in Microsoft Office Outlook Web App
  • Transport decryption, to decrypt IRM-protected messages to apply messaging policies
  • Journal report decryption, to attach a decrypted copy of IRM-protected messages to journal reports
  • AD RMS protection for Unified Messaging voice mail messages

For more information about IRM features, see Information Rights Management.”

Any questions?

Mass Changing Voicemail (Exchange 2010 Unified Messaging)

How many kilograms is your voicemailbox? Even if you knew, how would you change it? That’s not what this article is about. How would we take a massive number of people’s mailboxes and make changes to them? That’s the ticket, and we’re referring to Exchange Server 2010 hosted mailboxes with Unified Messaging. Yes, some of this article might even apply to Exchange Server 2007, but it’s focused on 2010.

Let’s say that the human resources department (or some of the other powers that be) have a spreadsheet or database of change requests for you. They want you to create some voicemail boxes for some people, delete others, reset some PINs, and in some cases create or delete a basic mailbox as well. Instead of tackling that whole solution in one article, we will start with one part of it – how would we enable voicemail for people with existing Exchange 2010 mailboxes?

If the words Exchange Management Shell (EMS) aren’t already ringing in your ears, perhaps you need to get up to speed on automation with Exchange 2010, Exchange 2007, and Windows PowerShell. Specifically, we’ll tackle this problem with at least two cmdlets. The first, Import-CSV, doesn’t exactly extract information from the spreadsheet or database directly (although that’s a far more interesting endeavor which PowerShell could tackle), but simply takes a comma separated values (CSV) file which could be exported out of Excel or other software. With a CSV file representing the change requests, PowerShell’s Import-CSV cmdlet can bring the data into quick grasp. Another cmdlet we’ll use is Enable-UMMailbox, which isn’t is basic PowerShell 2.0, but in the extensions which Exchange 2010’s EMS provides. This facilitates making the actual changes.

First, let’s look at an example change request file (changevm.csv):


newvm,Samantha,Spade,”Outbound Sales”,135790

newvm,Wanda,Wombat,”Outbound Sales”,444333



Each Unified Messaging Mailbox Policy includes a dial plan and other options. Consider the following pipeline.

import-csv changevm.csv | %{ $who = $_; switch( $_.request ){

newvm { Enable-UMMailbox -Identity $(Get-Mailbox “$($who.first) $($who.last)”) `

-UMMailboxPolicy $who.ummailboxpolicy -Pin “$($who.pin)” -PinExpired $false }

resetpin { Set-UMMailboxPin -Identity $(Get-Mailbox “$($who.first) $($who.last)”) `

-Pin “$($who.pin)” -PinExpired $true }

default { “Cannot handle {0} request for {1}” -f $_,”$($who.first) $($who.last)” }

} }

This looks at the keyword at the beginning of each line (the change “request” type), and supports both “newvm” (new voice mailbox) requests, and a “resetpin” requests, but also includes a default selector in the switch statement to alert you that this little code block doesn’t know how to handle other kinds of requests (but could easily be enhanced).

Note that the value of each person’s change request ($_) is saved in the $who variable just inside the ForEach-Object (%) loop because the switch construct also assigns the special variable $_, but with the value of its expression (inner pipeline) which is $_.request.

Exchange 2010’s Enable-UMMailbox cmdlet is used to create a unified messaging mailbox for voicemail and inbound faxes for a user with an existing mailbox. Their PIN is set to the value from the request file, and the PinExpired property is set to false so that the user doesn’t have to change it. This is a calculated security risk.

For the PIN reset scenario, the Set-UMMailboxPin cmdlet is used, and in this case we chose to set the PinExpired value to true so that the user must change their PIN when they next connect to their voice mailbox.

The sky’s the limit with automation and Exchange Server 2010. How often do you have to handle similar requests? The shell can help.

Enable-UMMailbox -Identity <MailboxIdParameter> -UMMailboxPolicy <MailboxPolicyIdParameter> [-AutomaticSpeechRecognitionEnabled <$true | $false>] [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-Extensions <MultiValuedProperty>] [-IgnoreDefaultScope <SwitchParameter>] [-NotifyEmail <String>] [-PilotNumber <String>] [-Pin <String>] [-PinExpired <$true | $false>] [-SIPResourceIdentifier <String>] [-ValidateOnly <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Moving Exchange Server 2010 Mailboxes

Moving mailboxes doesn’t have to be difficult – all you need is a bag of concrete mix, some water, a good shovel, some good solid posts, and of course the mailboxes in question. Oh wait, am I forgetting something? Right, the wheelbarrow to mix the concrete in and a hacksaw to cut down the old posts.

What? That’s not the kind of mailbox you’re talking about. Ah, I see, you wanted to know about mailboxes hosted on Exchange Server 2010. Excellent, then you’ve come to the right place. Just give me a minute to put away my trowel.

There are two kinds of mailbox move operations in Exchange Server 2010, local and remote, depending on the destination.

Local Move Requests: If the source and target mailboxes reside in database copies in the same server, then you can issue a New Local Move Request… in the Exchange Management Console (EMC) or in the Exchange Management Shell (EMS), a command such as ‘777.wernerconsulting.com/Users/Brad Werner’ | New-MoveRequest -TargetDatabase ‘Database Seven’ to create the move request.

The other kinds of request, a New Remote Move Request… is used when the source and target mailboxes are hosted in database copies which are not on the same Exchange Server as one another. There are several potential sources for the original location of the mailboxes with a remote move request. The source mailboxes could reside on another mailbox server which is in the same Active Directory site, in another site, a member of another domain, or even from a server which is a member of another Active Directory forest.

When the destination server is Exchange Server 2010, the remote move request tools of Exchange 2010 should always be used, even if the source servers are running Exchange Server 2007 or Exchange Server 2003. If you’re migrating from Exchange 2003, it’s probably tempting to want to use Active Directory Users and Computers (ADUC) to perform the moves to a new server, and you’re probably also trying to wean yourself from Exchange System Manager (ESM), but it’s time to start acclimating to some new tools. Even Exchange Server 2007’s Exchange Management Console (EMC) and Exchange Management Shell (EMS) based on PowerShell v1.0 just aren’t the right toolset either. Use the Exchange Server 2010 tools to move mailboxes now.

Who does the digging to move these mailboxes? It’s not the mailbox server, and it’s not like Exchange 2007’s Move-Mailbox cmdlet which did the work. Exchange 2010 Client Access servers run a service called Microsoft Exchange Mailbox Replication (MSExchangeMailboxReplication). So if you’re moving mailboxes from Exchange 2003 SP2, Exchange 2007 SP2, or even from Exchange 2010, this Mailbox Replication service (MRS) is used to move mailboxes from the source server(s) to the target server’s database. This architecture has a number of advantages over earlier version of Exchange.

Also, if you are moving mailboxes from either Exchange 2010 or Exchange 2007 SP2 to a target database on an Exchange 2010 server, it’s possible to do online moves. An online move operation can be taking place while the client (user) is accessing the mailbox. That extra advantage isn’t possible when moving from Exchange 2003 SP2, nor when moving to either Exchange 2003 or 2007 from 2010.

The ability to move mailboxes using a background service which will intelligently schedule, distribute amongst servers in the same site, and throttle server and network load is just one or many great features of Exchange Server 2010 which make this new messaging platform the best yet from Microsoft. If you’re using old versions of Exchange and aren’t at least planning for Exchange 2010, it’s seriously time to get ready.