All posts tagged Microsoft Exchange

By on May 31, 2013

Windows 8 Has Ruined My Life…Oh Wait Maybe Not

If this title sounds familiar, you’re likely to be someone who reads the technology media.

I mean let’s face it, ever since Microsoft announced its new operating system it had more than its share of critics appearing from every corner of the globe offering up their opinions (much like I’m doing now).

Microsoft has released screenshots confirming the return of a Start button to Windows 8

Microsoft has released screenshots confirming the return of a Start button to Windows 8

I don’t understand what the negativity is about.

I’m a Windows 8 professional user and I’ve been very happy with my upgrade from Windows 7 to Windows 8.

Before I continue, I just want to clarify a few things about myself and my history with Operating Systems because I’m not like the average user.

Like most, my first OS was a Microsoft OS (DOS 3.1 to give you an idea of my age) and I stayed within the Microsoft ecosystem for many years until one day in 1998 I decided to run a test to see if Linux was ready for the desktop. That test failed miserably but it instilled a love of all things Linux in me which I still have today.

In 2000, I moved to a fulltime Linux desktop as all the work I was doing was consulting and working around Linux systems. This continued to 2004 when a consulting project I was involved in required documents to be created in Office 2003 (Project and Visio). At that point I migrated from SuSE Linux 9.1 to Windows XP with Office 2003. That project completed and in 2005 I started working at Mimecast. My machine stayed on XP as I didn’t have the time to dedicate to migrate my data again.

My work at Mimecast brought me closer to Microsoft Exchange and Outlook and when they released Windows Phone I was excited to see what their re-imagining of the user interface would be like. The change from my BlackBerry Bold 9000 to the HTC HD7 was remarkable. Never before had I handled a phone that was so intuitive, user friendly and functionally useful to me. Sometime later I got “upgraded” to an iPhone 4s and – in what my wife and many others thought was a backwards step – I returned the iPhone and went back to WP7, this time to a Nokia Lumia 800. The iPhone wasn’t anywhere near as user friendly and intuitive as the Windows Phone was for me.

So when Microsoft announced Windows 8 and that it would be a similar experience to the Windows Phone, I was intrigued. I soon had a Lenovo Twist, a nice little machine with a touch screen that folds over and turns the laptop into a tablet and I began using it and reporting back to the IT department any problems I had or things I thought might be problematic for us as an organization to support.

I love being a guinea pig.

Anyway, barring basic issues like desktop AV clients not yet properly supported and drivers for my obscure Boogie Board Rip not yet working properly, everything has worked pretty much perfectly from day 1.

Yes, I’m not a basic user, but I ‘m a person who uses a lot of applications and is constantly moving between them. I’m someone who should, if the people who cry about the lack of start buttons and booting to desktops are to be believed, be miserable with this new OS.

Nothing could be further from the truth.

All in all, my life hasn’t really changed. I use the machine almost exclusively in desktop mode. Not because I don’t like the apps in the new UI, but because the tools I use on a daily basis are all on my desktop. I use Outlook, not the mail app, I use Word, not some note app, I use Excel not some calculator that can be obtained from the marketplace.

When I start up, I get dropped into the new start screen. Shock and horror, in order to begin my day I do what I’ve ALWAYS done. I start my mail client, Outlook. This is done by clicking or tapping the Outlook tile that I’ve positioned neatly in my direct line of sight on the start screen. Outlook starts and takes me into desktop mode.

I don’t miss the start button at all and it amazes me how much attention this insignificant little feature is getting. The start screen easily replaces the start button but if I am too lazy to jump around, I just use shortcuts. My taskbar in desktop mode has shortcuts to all my frequently used apps on it. (Microsoft have just announced that Windows 8.1 will include a start button but no start menu, among other much more exciting features but more on that later).

Both in my home office and my work office I’m connected to external displays and in almost every instance of using the machine I’m working with my keyboard and mouse.

My son uses the touch interface to play games. I don’t play games on this, I prefer to save the battery for more boring things like connectivity and spreadsheets.

That’s not to say I don’t go into the new UI ever because I do. My password management app is in the new UI.

So let’s recap.

I can do everything I need to do.

I don’t care that I’ve no start button because it doesn’t impact me in any way.

I work in desktop mode all day and the start screen doesn’t magically stop me being able to do this.

I switch between new UI and desktop all the time and I haven’t gone crazy.

So why’s everyone so anti this new operating system?

Beats me!

Add your comment (0)

Advocacy Development Director
Mimecast

Article Tags

, , ,

By on December 29, 2011

Microsoft Exchange Server: Yesterday, Today, and Tomorrow

Microsoft Exchange Server 4.0We don’t yet know what the next version of Microsoft Exchange Server will be called. Exchange 15 is an assumption based on the version number, the last being Microsoft Exchange Server 2010 which was version 14 (14.01.0218.015 for SP1, to be specific). We also don’t yet know when Exchange 15, or Exchange Server 2013 (based on the three year cycle) will be released into the wild.

So while we are waiting, here’s a quick look at the versions that have come before:

 

The Younger Half-Cousin Done Good – Exchange 1.0

Actually not a server product at all, Exchange 1.0 or Windows Messaging to give it its real name was an email client included in Windows 95, 98 and NT4. The fashion at the time, 1996, was to lack support for Internet email so if you were looking for SMTP or POP3 support you were out of luck unless you installed the separate Microsoft Plus! pack, codename ‘Frosting’. Frosting included other delights such as Space Cadet Pinball, DriveSpace 3 and some space-age screensaver and wallpaper files.

Windows Messaging had us hooked though; we never looked back. In 1996 HTML messages were evil, our marketing departments hadn’t yet realized how to brand plan text emails yet. It was de rigueur to include an obscure quote in your footer, and if you were really out to impress, a string of special characters on the verge of ASCII art. There was no support for international characters either; sorry, the rest of the world you lose.

The First Server, Server Product – Exchange 4.0

The server side of the business came crashing through the door one day wanting in on the new funky Windows Messaging action. Exchange Server 4.0 was born as an upgrade to Microsoft Mail 3.5, which in 1991 was slowly turning into something called Network Courier in. Lotus were very excited about acquiring cc:Mail at about the same time, so the race was on.

Our CEO, Peter Bauer still proudly displays his Microsoft Mail 3.5 certifications on the office wall.

Exchange Server 4.0 was a wholly new system, designed on the X400 client-server model, supported by a single database and an X500 directory service, which later morphed into Active Directory.

1997 Microsoft Valued at $261 Billion and Exchange Server 5.0

In the year Microsoft becomes the World’s most valuable company, and Bill Clinton is returned to office for a second term, as is Steve Jobs; Microsoft release Exchange 5.0 and the new Exchange Administrator Console.

Adding the new Internet Mail Connector allowed your new shiny Exchange 5.0 server to communicate over the internet via SMTP, for the first time allowing your users to arrange their days around the send/receive button. Exchange 5.0 also introduced a new-fangled web-based email interface uninspiringly called, Exchange Web Access.

A Few Short Months Later – Exchange Server 5.5

In November 1997 while the tech world was distracted by the $37 Billion merger of WorldCom and MCI Communications, Microsoft snuck out Exchange 5.5, which was sold in two editions, Standard and Enterprise. Standard was limited to a 16GB database which was a throwback to previous versions, whereas Enterprise Edition had a database limit of 16TB. I remember building a business case for Enterprise Edition and having to explain to the business why 16GB wasn’t enough – if only we knew then what we know now.

Drum Roll Please, Ladies and Gentlemen Exchange 2000 Server

By November 2000 we’re on Exchange Server version 6.0, codename Platinum. A big leap forward with changes to support clustering and database size limitations. But, the upgrade required there to be a complete Microsoft Active Directory infrastructure on the network as there was no built-in directory. There was no in-place upgrade from previous versions of Exchange, so consultants and Microsoft Partners made merry with the consulting hours as customers required both platforms to be online at once.

Codename Titanium – Exchange Server 2003

Version 6.5 added some useful migration tools that helped companies consolidate their distributed Exchange environments; I have a true story that demonstrates this perfectly.  One client of mine, who had twenty different Exchange Servers, one for each letter of the alphabet, distributed users depending on their surname, doubling up for some of the less common letters like X, Y & Z. All twenty servers, none of which were virtualized, sat in the same datacenter in central London. How they got to this stage was a long story, but the realization that Exchange Server 2003 could help them resolve this problem saw twenty servers whittled down to a handful of streamlined clusters in four locations across the globe.

Bells and Whistles and a Big Fanfare – Exchange Server 2007

Exchange Server 2007 was released amid much fanfare and marketing by Microsoft, and rightly too, this version brought some wonderful new technologies and functionality. Sadly though some users chose not to upgrade and stayed languishing on Exchange Server 2000 and 2003, I even knew a few still on 5.5!

64 bit support was a bit of a struggle for some customers, but eventually gave every IT department the budget to upgrade their old Exchange Server to a new, faster one. The 2007 release was version 8, codename E12 and brought and Enterprise Edition which allowed a whopping 16TB maximum database size.

HA Database Clustering was given a whole new batch of TLAs;, SCC, LCR, SCR and CCR. The Exchange Management Shell arrived as did Unified Messaging and Outlook Anywhere (which was really called RPC over HTTP).

However Microsoft announced the death of Public folders in the next release, due to what they call a ‘Wild West’ of public folders.

Which Brings us Right up to Today – Exchange Server 2010

November 2009: Exchange Server 2010, or Exchange 14 to those in the know, hit the market brimming with cool new features. Database Availability Groups or DAGs became even more popular than ever before replacing the Clustering options from Exchange Server 2007. Server Roles became important to Exchange Architects everywhere and sparked much debate about where in the network to put the CAS.

Luckily large mailbox support was extended after its initial introduction to Exchange Server 2007, which was good news for most as their end users had been using disk space like there was no tomorrow and databases everywhere were getting rather full. To this day I know an end user who refuses to ‘clean out’ their 32GB mailbox on the basis that he “needs” all of that email and knows “exactly where it all is” – you know who you are sir, if you’re reading this.

Public Folders are included in 2010 and not deprecated as planned.

Unfortunately some businesses are still languishing on old versions like Exchange Server 2000 and 2003. You also know who you are, and you know how keen we are to get you to Exchange Server 2010.

Enter the Cloud – Office 365

Luckily for administrators dealing with “Mr. I’ve got a Huge Mailbox & I don’t Care” the Cloud started to make life easier, by offloading some of those Big Data and Email Management issues. Microsoft have just launched Office 365 and introduced Exchange Online. Although EO has been around since about 2005 and mainstream since 2008, it’s only now that users are beginning to see the real benefits of the Cloud.

Enter Exchange 15

What Exchange 15 or Exchange Server 2013 will bring is still shrouded in Mystery, even the Servers real name is unknown (I hoping for “Philip”) but it’s just round the corner and slowly information is trickling out of Redmond.

Personally, I can’t wait.

 

Add your comment (1)

CISSP, CCSK
Mimecast

Article Tags

, ,

By on December 27, 2011

Future-proofing your Microsoft Exchange Upgrade & Migration Strategy

Back to the Future time machineThe future… if we actually had an endless supply of dilithium crystals or flux capacitors, gadgets like floating skateboards and Tricoders might be more common. But sadly they’re not; so the only real prediction I can make for the future (that’s relevant to this blog post anyway) is that Microsoft are planning to release a new version of their Exchange Server software every three years. We should be seeing the next version towards the end of next year, currently being called Exchange 15.

Like Christmas, it feels like new versions of core server software come round far too quickly, especially such valuable services like Microsoft Exchange. We’ve previously mentioned the lengthy procurement cycles that keep such services a constant version behind before, which generated some good feedback and discussion; many Exchange admins told me those delays adversely impact their own deployment plans, which is intensely frustrating for them and often forces their migration project into the red.

So, rather than roll out the ubiquitous predictions for 2012; I’m going to suggest that in the absence of 1.21 Gigawatts you can take a stab at future-proofing your Exchange environment now, so you’re not left thinking in future -

“I’m migrating again. Surely not? Didn’t I just finish the last upgrade?”

However the last migration or upgrade you performed was probably a little easier; the requirements were different then, and there was dramatically less data than today. The move from Exchange 2003 to 2007 was mostly about the new 64 bit hardware required, but the move to Exchange 2010 is often about the volume of data instead.

As your users make merry with the disk space allocated to the Exchange Stores, their mailboxes have grown and grown, you’re probably wondering how you’re going to move several Terabytes of data to the new Exchange platform; but, more importantly wondering when you might have to do this again. The short-term nature of IT and the constant cycle of upgrades and migrations means you may have to answer those question sooner than you expected.

One simple solution that future-proofs your migration and upgrade strategy is to deal with the data now by augmenting your on-premise Exchange with a Cloud based email management solution. Using this Cloud based email management solution is simple; the elastic and scalable nature of the Cloud lets you ‘dump’ your oversize email stores into a secure, scalable, flexible and resilient solution that will grow with you, but at the same time allow the users to have direct access to that email data through Outlook as though it was still on Exchange.

Now here’s the part of plan we don’t talk about very much, but one that provides a great degree of flexibility. When the next migration or upgrade comes around, or if you want to move from one platform to another, having already dealt with the data means your core email service i.e. Exchange, can be anywhere or anything. Upgrade, downgrade, move to Office 365 and back again, migrate some users or all users, the choice is yours; Augmenting Exchange with the cloud means you’re not tied to any one solution or version, both today and next year when it’s time to upgrade again.

 

 

 

 

 

 

Add your comment (0)

CISSP, CCSK
Mimecast

Article Tags

, , ,

By on December 9, 2011

Velocity: How fast is your Exchange Server Store growing?

Blurred vehicle lights and cityscapeThis week Mimecast has been at the Gartner Data Center Conference 2011, in Las Vegas, with a packed agenda full of insightful discussions and presentations. As expected the Cloud was a strong trend throughout the week, but I couldn’t help but notice that another trend has emerged since the last summit; that of Big Data, a topic this blog has written about many times before.

One particularly compelling presentation by Gartner Research VPs, Merv Adrian and Sheila Childs delved into Big Data. The packed session was standing room only, so this is obviously a hot topic for people looking for insight to help them solve their own unique problems.

Adrian and Childs identified a shortcoming in the way business and technology leaders talk about big data, in that the emphasis is often placed on volume. They rightly pointed out that

“The most difficult information management issues emerge from the simultaneous and persistent interaction of extreme volume, variety of data formats, velocity of record creation and variable latencies, and the complexity of individual data types within formats.”

As we’re concentrating on volume of data, we’re often forgetting about the velocity, variety and complexity of the data too.

Adrian and Childs went on to quantify velocity, which is when I started relating it to email data and Exchange Stores.

Velocity involves streams of data, structured record creation and availability for access and delivery. Velocity means both how fast data is being produced, and how fast the data must be processed to meet demand.

The most important factor when it comes to thinking about Big Data in relation to Microsoft Exchange Server, in my opinion, is velocity. Of course most Exchange databases won’t have the sort of big data that most data center managers have to worry about, but to those of us who manage Exchange Servers, I’ll bet the data therein is one of the largest repositories of data in your environment. To coin a phrase of our Chief Scientist, you have essentially got a Nano-Google’s worth of data, it’s important to you, but nothing that hasn’t been dealt with before, but trying telling that to the Exchange administrator when they’re planning to migrate the stores from one version of Exchange to another.

So what is the Velocity of your Exchange Server? If Velocity is the stream of data, record creation and availability for access and delivery, I’m sure there must be a quadratic equation that will actually give us a figure for this. But I was thinking more about it in terms of every day reality, especially if that reality means an upgrade or migration.

The unique big data complexity that exists within each Exchange environment is compounded by the velocity of the email environment that surrounds it. The data will continue to grow at a rate that can only be determined by a number of local factors; corporate culture, use of email, access to email, integration of email into other systems. Again, I’m sure there is a quantitative way to work out what this velocity is.

When you’re thinking of doing something with your nano-Google Exchange store I would suggest that getting a grip on the velocity of Exchange is the first step. I doubt very much that you can do anything to throttle this velocity, not without upsetting your users at least. So I’m drawn to the phrase “Just Enough on Site” which is one we use at Mimecast, to describe an Exchange environment that has been given the benefit of Cloud Augmentation to take the Big Data load off said server, before, during and after a tricky migration.

I would argue that the amount of ‘online’ data needed in an Exchange Server is pretty minimal, probably about a month or two. The rest doesn’t need to be offline, but keeping it near-line is way more productive. Remember velocity is also about how fast the data must be processed to meet demand. Surely putting the less accessed and older data near-line in the cloud means your Exchange can concentrate on the on-line velocity of the real time data?

 

 

 

 

Add your comment (0)

CISSP, CCSK
Mimecast

Article Tags

, , , ,

By on November 23, 2011

Migrating Exchange at the moment? 2007 or 2010?

Microsoft Exchange MigrationMimecast recently commissioned Loudhouse, an independent research consultancy to take a look at the Exchange Migration situation. The research tells us that there is a mass migration of Microsoft Exchange Servers going on right now. At Mimecast we call this ‘The Great Email Migration’ and some interesting facts and figures have been discovered.

Underneath the headline research figures there is a lot going on that struck me as interesting if not perplexing and clearly frustrating; I’m often talking to CIOs and IT Managers about their email infrastructure and recently their plans to migrate to the next version of Microsoft Exchange Server; I’m always assuming they’re planning to upgrade and migrate to Exchange 2010 or Office 365, but I’m hearing more and more choosing to stay a version behind on Exchange 2007, but not for want of trying.

Microsoft, and in fact Mimecast, are desperate to get you all off the old versions of Exchange, away from those Exchange 2000 or 2003 boxes that are still out there, but for so many the upgrade path stops at Exchange 2007. I began to wonder why this is, and after a quick unofficial straw poll I found a pattern emerging.

Firstly I noticed that upgrade plans for Exchange have been in the pipeline for quite a long time. Many people tell me they were planning to upgrade from 2000/2003 versions to Exchange to 2007 pretty much as soon as they heard about the new release. But given the scale of the upgrade the project took them longer to budget and plan for, most blame their own internal and overly complex procurement process; whereby a non-technical procurement employee veto’s or delays the project for trivial reasons.

Secondly, I’ve heard quite a few mentions of a “patch-and-pray” mentality to upgrades. Let me be clear, there is only so long this kind of support process lasts before your Exchange Admin is facing a late night and lost weekend due to some sort of failure, and that’s the last thing we want. At some point the CIO has to admit the business and the users have outgrown their email environment and it’s time to look elsewhere; but this overly cautious approach, akin to the “if it ain’t broke don’t fix it” method, means you’ll never be close to the latest version. Fear of change, hesitation and caution are the enemy of new technology.

All of this frustrating behavior adds up to significant delays; delays that leave your IT project plans looking like the airport departures board during a heavy snow storm. You know you’ll get there in the end, but the wait is agonizing and you would do almost anything just to “get on with it.”

A permanent cycle of delays means your Exchange environment could always be stuck a version behind. Given that Microsoft plan to release a new version of Exchange every three years, I’m always concerned when I hear of project life-cycles that are even longer; how can you possibly take longer to deploy the platform, than it took the vendor to write the software in the first place? Don’t answer that I already know how; project scope, evaluation, planning, more planning, more evaluation, procurement, re-scoping, procurement, deployment planning, re-scoping, procurement, and so on. Initial project evaluation to final deployment for Exchange 2007 could have taken so long, that Microsoft have released Exchange 2010 in the meantime. And so the cycle continues.

Breaking the upgrade cycle is something I’ve written about before; now is the time. Seriously, Exchange 2010 is worth the effort, especially if you’re still floundering about with old versions like 2000 and 2003.

 

 

Add your comment (0)

CISSP, CCSK
Mimecast

Article Tags

, ,

By on October 20, 2011

Minimizing the risk of an email migration

Last week Mimecast announced the results of their Great Email Migration research, conducted by Loudhouse Research.  Loudhouse surveyed 500 IT decision makers in the US, UK and South Africa and asked them about their email migration plans.

According to the report, “The potential loss of data is at the top of the list with more than half (52%) of the companies mentioning this.”

Companies are right to be concerned at the possibility of data loss. Infrastructure which is in flux opens companies up to be vulnerable to data loss, due to bad process, unmanaged configuration change and/or bad discipline. How can companies possible hope to mitigate these kinds of risk.

It is an old axiom that failing to plan is tantamount to planning to fail. In this context, planning should be a formal activity of every migration project, with a formal and on-going deliverable known as the migration plan.

Migration plans are only as good as the effort put into them and the accuracy of the scope which they are fed by. Accurate quantification of source environments, labs which approximate live environments, and a sample of representative user data are all prerequisites to ensuring a migration plan has the best possible chance of succeeding.  In fairness, most of us don’t migrate for a living, so it’s not unreasonable to expect not knowing where to start. Here we will offer two suggestions:

Follow the military approach to planning by starting with the end goal in mind, and working backwards through every objective until the base understanding of the requirement is defined, without knowing how to solve every objective or process requirement. The end goal must be a clearly defined business or technical requirement.

Follow up by adding process planning for each stage, known or unknown, and add technology choices last, so that technology becomes the enabler to the process, and not the other way around.

Migrations are epitomised by environments in flux. Flux is risky and is mitigates by process, planning and management. Migration planning as an on-going exercise as well as a living document is a foundation stone in the on-going exercise to mitigating on-going risk.

Add your comment (0)

Messaging Architect
NB Consult

Article Tags

, ,

By on October 12, 2011

The Great Email Migration

Microsoft Exchange 2010 is here, Exchange 2013 will be along at the end of next year and Exchange 2003 is out of mainstream support, so it’s fair to say The Great Email Migration has begun.

At Mimecast, we are always talking to CIOs and IT Managers about ways in which we can make their email management easier, and the conversation more often than not involves plans for migration.  So, we commissioned Loudhouse,an independent research consultancy, to conduct a survey into email system upgrade plans. The results are being published today.

The rush to upgrade

With so many new features and enhancements being added to each new version of Microsoft Exchange it’s no surprise that three quarters of respondents told us they were planning to upgrade in the next two years; 57% even said within the next 12 months. Most are migrating to Exchange 2010 on premise, but 21% are headed for the hosted option and 13% for Microsoft’s Cloud-based Office 365.  As you read this, there’s a 1 in 10 chance that you have no plans to migrate at all, perhaps having recently completed a move to Exchange 2007.  Maybe you want to see what  Exchange 2013 (version 15) will bring? We’ve written on this blog before about Exchange 2003 and a reluctance to upgrade, but now the time is right.

The benefits are clear

Continue Reading →

Add your comment (0)

CISSP, CCSK
Mimecast

Article Tags

, ,

By on August 22, 2011

Get Full Control over your Exchange remote PowerShell session

[Another great post from Shay Levy - original available here]

PowerShell 2.0 supports two kinds of remote configurations: fan-in and fan-out. When we execute a command against a bunch of servers we use fan-out (one to many). Fan-in is used when multiple users are connecting to a remote server (many to one). Exchange server implements a fan-in configuration via a virtual directory on the Exchange server’s IIS. We can connect to the virtual directory (http connection) and manage our Exchange server remotely, without having to install the Exchange Management Tools locally on our admin station.

We can create a remote session (using the currently logged on credentials) with the New-PSSession cmdlet.

If you need to connect with alternate credentials, add the –Credential parameter:

PS > $uri = 'http://dc1.homelab.com/PowerShell'
PS > $session = New-PSSession -ConfigurationName Microsoft.Exchange `
               -ConnectionUri $uri -Authentication Kerberos

The session is created and we can import the commands from the remote session into our local session and use them as if they were installed locally (aka, implicit remoting).

PS> Import-PSSession –Session $session

When the session finished importing, all commands from the remote session are available in our local session. In the background a module is created that contains all remote commands. Let’s try one command:

PS > Get-MailboxDatabase

Name                           Server   Recovery  ReplicationType
----                           ------   --------  ---------------
Mailbox Database 0311695863    DC1      False     None

Now let’s try to get the database size:

PS > $db = Get-MailboxDatabase -Identity 'Mailbox Database 0311695863' -Status
PS > $db.DatabaseSize
152.1 MB (159,449,088 bytes)

We get back the size of the database in MB and in bytes. Exchange supports several methods to format the size of an object (mailbox/database) through a series of methods: ToBytes(), ToKB(), ToMB() etc. Let’s try to format the size of the database and get the value in bytes:

PS > $db.DatabaseSize.ToBytes()
Method invocation failed because [System.String] doesn't contain a method named 'ToBytes'.
At line:1 char:25
+ $db.DatabaseSize.ToBytes <<<< ()
    + CategoryInfo          : InvalidOperation: (ToBytes:String) [], RuntimeException
    + FullyQualifiedErrorId : MethodNotFound

We get an error that the DatabaseSize property doesn’t contain the ToBytes method. We can also see that DatabaseSize is a String. This is the expected behavior in a remoting session. When a source computer sends a script to a remote computer, the code is serialized first (converted to XML), when it gets to the destination machine it’s converted back (deserialized) and executed. The result is serialized again and sent back to the source computer. It is important to understand that when the source computer gets the final result, it convert it back to objects but the objects are “dehydrated”, and contains a bunch of Note properties and one method – ToString (some “primitive” types, like Int, can be deserialized better than others). As a consequence, if we want to execute methods on the “real” object we need to do that on the remote end. When we want to get hold of the object itself (and it’s members) we invoke the command on the remote end with the Invoke-Command

cmdlet:

 
PS > $identity = 'Mailbox Database 0311695863'
PS > $sb = {(Get-MailboxDatabase -Status –Identity $identity).DatabaseSize.ToBytes()}
PS > Invoke-Command -Session $session -ScriptBlock $sb

Method calls are not allowed in restricted language mode or a Data section.
    + CategoryInfo          : ParserError: (ToGB:Token) [], ParseException
    + FullyQualifiedErrorId : MethodCallNotSupportedInDataSection

Another error! We cannot run methods in restricted language mode. What does this mean? The Exchange configuration is locked down (restricted session). By default, only administrators can connect to the end point, but they are restricted as well!

A few words on LanguageMode. There are three possible values: NoLanguage, RestrictedLanguage, and FullLanguage. In FullLanguage you can do whatever you want. In NoLanguage mode only commands that are using the Runspace APIs are allowed, and in RestrictedLanguage mode commands that contain scripts that need to be evaluated are not allowed.

This was a bit disappointing. If the server admin cannot have full access to the remote session then who can? I’m not sure why the Exchange team decided to lock the environment. The notion of connecting to any remote server and managing it without having to install local tools is not fulfilled here.

I started to look for a way to bypass that limitation and it appears that I was looking in the wrong direction! Hats off to my friend, MVP Aleksandar Nikolic, for a great tip! We can change the language mode by opening the web.config file in the PowerShell virtual directory:

 

 

 

 

 

 

I changed the value to FullLanguage, saved the file, recycled the MSExchangePowerShellAppPool application pool and re-created a remote session:

PS > $uri = 'http://dc1.homelab.com/PowerShell'
PS > $session = New-PSSession -ConfigurationName Microsoft.Exchange `
-ConnectionUri $uri -Authentication Kerberos
PS > $identity = 'Mailbox Database 0311695863'
PS > $sb = {(Get-MailboxDatabase -Status –Identity $identity).DatabaseSize.ToBytes()}
PS > Invoke-Command -Session $session -ScriptBlock $sb
159449088

And it worked, we can invoke methods in the remote session without having to parse strings. The final step was to create a separate environment, for admins only, one that doesn’t change the original configuration made by the Exchange team. I reverted back the value in the web.config file and wrote the following script to automate the process. Log on to your Exchange server, open PowerShell (not EMS) and run it (comments inline):

# load the IIS module
Import-Module WebAdministration

# get the path to the exchange server installation directory
# and create a new folder for the exadmin application
$path = ‘HKLM:\SOFTWARE\Microsoft\ExchangeServer\v14\Setup’
$exbin = Join-Path (Get-ItemProperty $path).MsiInstallPath ClientAccess
$folder = New-Item -Path $exbin\exadmin -ItemType Directory -Force 

# copy the web.config file to the new directory, load it (as xml) and
# change the language mode (from RestrictedLanguage) to FullLanguage
Copy-Item $exbin\PowerShell\web.config $folder.FullName -Force
[xml]$wconfig = Get-Content $exbin\exadmin\web.config
$wconfig.configuration.appSettings.add.value = 'FullLanguage'
$wconfig.Save("$exbin\exadmin\web.config")

# Create a new IIS application pool, and start it
$pool = New-WebAppPool -Name exadmin

# Configure the exadmin app pool to run under the LocalSystem account (0)
Set-ItemProperty IIS:\AppPools\exadmin -Name ProcessModel -Value @{identityType=0}

# start app pool
Start-WebAppPool -Name exadmin

# Create a new IIS Web Application.
$application = New-WebApplication -Name exadmin -Site 'Default Web Site' `
-PhysicalPath "$exbin\exadmin" -ApplicationPool $pool.name

#Set the application SSL settings to accept client certificates (if they are provided)
Set-WebConfigurationProperty -Filter //security/access –Name SslFlags `
-Value SslNegotiateCert -PSPath IIS:\ -Location 'Default Web Site/exadmin'

# create new end point configuration and allow administrators to remotely run commands
# a dialog is shown with the local administrators group selected, and we can add
# users/groups we want to have access to the end point
#Get-PSSessionConfiguration exadmin | Unregister-PSSessionConfiguration -Force
Register-PSSessionConfiguration -Name exadmin -Force
Set-PSSessionConfiguration -Name exadmin -ShowSecurityDescriptorUI -Force

# testing the new environment, uncomment and change database identity
# create a fan-in session (notice we are connecting to exadmin) and try to
# invoke the ToBytes method – it works
#$sb = { (Get-MailboxDatabase -Status -Identity 'Mailbox Database 0311695863').DatabaseSize.ToBytes() }
#$uri = ‘http://dc1.homelab.com/exadmin’
#$session = New-PSSession -ConfigurationName Microsoft.Exchange –ConnectionUri $uri
#Invoke-Command $session –ScriptBlock $sb

Now you can connect from any computer that has PowerShell 2.0 installed to your Exchange server and gain full access. I hope this has been helpful, here’s some related resources you may find useful as well:

How objects are sent to and from remote sessions
Configuring PowerShell for Remoting – Part 1
Configuring PowerShell for Remoting – Part 2 (Fan-In)
Administrator’s Guide to Windows PowerShell Remoting
Layman’s Guide to PowerShell 2.0 remoting
Deep Dive video: Constrained PowerShell Endpoints – Aleksandar Nikolic
Book: Microsoft Exchange 2010 PowerShell Cookbook – Mike Pfeiffer

Add your comment (1)

Advocacy Development Director
Mimecast

Article Tags

, ,

By on August 1, 2011

Simplify your Cloud Migration

Migrating to the Cloud at the moment? Or at least planning to sometime soon? Lots of businesses are either moving key IT services out to the Cloud right now, or are planning to in the near future. Many organizations have adopted the “Cloud First” ethos, of procuring Cloud solutions for new platforms, rather than on prem.

Most IT departments I talk to have a solid plan for these migrations, a plan that’s been well thought out and even tested; but I think it’s fair to say some don’t. The latter is usually found when a C-level manager has dictated the use of a Cloud solution in a “get it done and don’t bother me with the details” type of management style. Very 1997 I know – I thought those days were over, Mr Gekko?

IT departments are unlikely to declare IT Bankruptcy and ship everything out to the Cloud over the next long holiday weekend, even if there is pressure from the C suite to get ‘Cloud first’ apps in place as quickly as possible. Migrating systems to the Cloud, needs careful planning and consideration, not just the move itself but an understanding of the data, processes, policies, APIs, people, & supporting platforms involved. In other-words, the details.

Take a move to the latest version of Microsoft Exchange for example. Of course I mean Office 365, but many businesses are still thinking about how best to get to Exchange 2010; you see they’re still lingering on their trusty Exchange 2003 infrastructure. We have spoken before about the complexity of the peripheral applications that surround the Exchange Server being a hindrance to a migration project, and how dealing with this complexity makes you and your business ‘Migration Ready‘. Most of the careful planning and consideration has to take into account all those peripheral applications and services first, extending the scope of the project into, perhaps, much more than was first considered. Hardly surprising we lose track of the details and start to focus on the final outcome.

So let’s stick with Microsoft Exchange as an example: How about this as an alternative strategy to get your business to the cloud. At Mimecast we often talk about a strategy called “Just Enough on Site” which is about finding the balance between on-site and Cloud. You’re augmenting your network with Cloud. Exchange 2010 is an on-ramp to Office 365 Exchange Online – what do I mean by that? Well, rather than try to move everything and everyone to Office 365 Exchange Online now, simply take your time. The Exchange 2010 migration should be a focused move to a platform that will allow you to introduce the Cloud into your business in small well planned steps.

Jumping into standing up cloud instances all over the place might work, but it’s far better to take your time to sweat the details for a while, and think about how you and introduce the cloud to the network over a number of smaller migrations rather than one great big one.

As they say round here – “Let the network see the cloud”.

Add your comment (0)

CISSP, CCSK
Mimecast

Article Tags

, ,

By on June 14, 2011

Guest Post: Migrating between email servers- SMTP Namespace Sharing (Part 2)

Fourth in our series of Guest posts by Exchange MVP’s is Clint Boessen, in the last post he explored the complexities of sharing an email domain- known as a SMTP namespace- essential when migrating between servers or running multiple mail servers. In this post he walks you through the technical steps needed to achieve this when migrating from 2003 to 2010.

Clint Boessen is an Exchange MVP from Western Australia focusing on Microsoft Business Productivity solutions.  Clint works for 4Logic Pty Ltd, an Information Technology and Consulting Company who is a Microsoft Partner predominately focusing on Microsoft.  Clint has a diploma in Network Engineering, an MCSE, MCITP and is currently working towards his MCM in Exchange Server. Clint maintains his own blog containing lots of hints, tips and tricks for IT Professionals which can be viewed at http://clintboessen.blogspot.com.

Part 2: Configuring SMTP Namespace Sharing between Exchange 2003 and Exchange 2010 organizations

Welcome to part two of this three part series on SMTP Namespace sharing. In part one of this series we had a look at what SMTP Namespace sharing is and how it can be configured across multiple email systems. If you missed part one of this series you may view it here Part 1: An overview on SMTP Namespace Sharing.

In part two we are going to look at how to configure SMTP Namespace Sharing between two Active Directory forests. One forest will run Exchange 2003; the other will run Exchange 2010. I have created a lab environment for our two forests which I have used to document the configuration steps. SMTP Namespace Sharing will be setup for @contoso.com.

SMTP Namespace Sharing on Exchange 2010

The first thing we need to configure in Exchange 2010 for SMTP Namespace sharing is the accepted domain. Accepted domains are any SMTP namespace for which an Exchange organization sends and receives e-mail for a given SMTP Namespace. Accepted Domains can be configured in one of 3 ways:

  • Authoritative Domain To specify that e-mail messages are delivered to a recipient that has a domain account in your Exchange organization, select this option.
  • Internal Relay Domain To specify that e-mail messages are either delivered to recipients in your organization or relayed to a server outside your Exchange organization but still under the authority of your company or IT department, select this option.
  • External Relay Domain To relay e-mail messages to an e-mail server outside the Exchange organization, select this option.

To configure SMTP Namespace Sharing for @contoso.com we must setup @contoso.com as an Internal Relay Domain.

Now that Exchange 2010 is able to accept email for @contoso.com provided we have our Receive Connectors configured correctly. Now we must create a Send Connector to route the email to the Exchange 2003 forest for any unresolved recipients. Follow the below steps for setting up the Send Connector:

Note: To achieve the correct routing behavior, you must specify a Hub Transport server as the source server for the Send connector. If the Edge Transport server is specified as the source server for the Send connector, a routing loop will occur.

  1. In Exchange Management Console under Organization Configuration à Hub Transport click New Send Connector on the action pane.
  2. Provide the Send Connector a descriptive name. The usage type determines the default permissions sets that are assigned on the connector and grants those permissions to the trusted security principals.
  • Internal Select this usage type if the e-mail system with which Exchange 2010 shares an address space is another Exchange 2010 organization
  • Internet Select this usage type if the e-mail system with which Exchange 2010 shares an address space is a third-party e-mail system.

Select Internet as the foreign email system is Exchange 2003.

  1. On the Address space page, click Add. In the SMTP Address Space dialog box, enter the domain name to which this connector will send mail, for example, contoso.com or *.contoso.com. You may select the Include all subdomains check box to use this connector to send e-mail to all subdomains of the address space. If necessary, you can also provide a specific cost for this connector. When you’re finished, click OK. Leave the Scoped send connector check box cleared, and then click Next.

  2. On the Network settings page, select Route mail through the following smart hosts. Click Add.
  3. In the Add Smart Host dialog box, select IP Address or Fully qualified domain name (FQDN) to specify how to locate the smart host. If you select IP Address, enter the IP address of the smart host. If you select Fully qualified domain name (FQDN), enter the FQDN of the smart host. The sending server must be able to resolve the FQDN. When you’re finished, click OK. To add more smart hosts, click Add, and repeat this step. If you want to use a specific list of external DNS servers instead of the DNS servers specified in the adapter settings, select the Use the External DNS Lookup settings on the transport server check box. When you’re finished, click Next.

  4. On the Configure
    smart host authentication settings page, select the method that’s used to authenticate to the smart host. The following smart host authentication methods are available:
  • None
  • Basic Authentication
  • Basic Authentication over TLS
  • Exchange Server Authentication
  • Externally Secured (for example, with IPsec)

Exchange 2003 by default automatically allows Anonymous email from all IP addresses on its internal subnet. As a result choose None under Authentication type.

Note: It is recommended to configure Basic Authentication over TLS in production environments.

  1. Click Next.
  2. On the Source Server page, click Add to add a source server. By default, the Hub Transport server that you’re currently working on is listed as a source server. In the Select Hub Transport or Subscribed Edge Transport dialog box, select the Hub Transport servers that will be used as the source server for sending messages to the shared address space. When you finish adding source servers, click OK. Click Next.

  3. On the New Connector page, review the configuration summary for the connector. If you want to modify the settings, click Back. To create the Send connector by using the settings in the configuration summary, click New.
  4. On the Completion page, click Finish.

SMTP Namespace Sharing on Exchange 2003

Configuring Exchange 2003 for SMTP Namespace sharing is very different to Exchange 2010. Exchange 2003 must be authoritative for the primary SMTP address space that is specified in the default recipient policy. Exchange 2003 does not have to be authoritative for any other SMTP address space configured on the default recipient policy. To configure SMTP Namespace sharing we must ensure Exchange 2003 is not authoritative for @contoso.com as this will not allow Exchange 2003 to forward unresolved recipients for @contoso.com to Exchange 2010. As Exchange 2003 must be authoritative for the primary SMTP address specified in the default recipient policy we must create a second recipient policy to set @contoso.com as primary and then click to clear the This Exchange Organization is responsible for all mail delivery to this address check box in the SMTP Address Properties dialog box. This creates the same effect as configuring “Internal Relay Domain” on an Exchange 2010 Accepted Domain shown above.

Currently my Exchange 2003 server has @contoso.com setup as my primary SMTP Address on my default recipient policy. As you see I am unable to unselect This Exchange Organization is responsible for all mail delivery to this address as it is the default policy.

We need to share the @contoso.com SMTP address space which is specified as the primary SMTP address space in the default policy. As a result we must create a new SMTP address space in the default recipient policy. The new primary SMTP address space that you create does not need to be valid in the Internet DNS. You can use a private SMTP address space such as @localhost or @example.local. In this lab environment we will be using the address space @source.local which Exchange 2003 will use to route internal e-mail messages.

Perform the following configuration on your default recipient policy.

  1. Start Exchange System Manager, click Recipient Policies, right-click Default Policy, and then click Properties.
  2. In the Default Policy Properties dialog box, click the E-Mail Address (Policy) tab, and then click New.

  1. In the New E-mail Address dialog box, click SMTP Address, and then click OK.
  2. In the SMTP Address Properties dialog box, type the SMTP address space for which you want Exchange to be authoritative.
  3. Click to select the This Exchange Organization is responsible for all mail delivery to this address check box, and then click OK.

  4. Click the new SMTP address that you created, and then click Set as Primary.
  5. Remove the SMTP address that you want to share from the default recipient policy. To do this, click the SMTP address that you want to share, and then click Remove.

Now create a new recipient policy to be used for SMTP Namespace sharing.

  1. Create a new recipient policy for the shared SMTP address space. To do this, right-click Recipient Policies, point to New, and then click Recipient Policy.

  1. In the Properties dialog box, type a name for the new recipient policy, click Modify, and then click OK.

  2. Click the E-Mail Addresses (Policy) tab, and then click New.

  3. Click SMTP Address, and then click OK.
  4. In the Address box, type the SMTP address space that you want to share. For example, type @example.com, or type @microsoft.com. In this lab we used @contoso.com.
  5. Click to clear the This Exchange Organization is responsible for all mail delivery to this address check box, and then click OK.

  6. Click the new SMTP address that you created, and then click Set as Primary.

  7. Click OK, and then click Yes when you receive the following message:

    Note: If you use the above procedure and update user SMTP addresses using a recipient update policy, ensure a system state backup of Active Directory is performed on a domain controller before commencing the changes. ADModify.NET is an alternative way for updating user SMTP email addresses if the recipient update service is disabled. This is often the preferred way of performing the task as ADModify.NET allows you to revert changes.

After you configure the recipient policy for SMTP Namespace sharing, you must specify the means for Exchange to determine where to route messages that do not resolve to an object in Active Directory. To do this, create an SMTP connector that has the shared SMTP address space in the Add Address Space dialog box of the connector object. If you do not add the SMTP connector with the shared address space, any incoming e-mail that is destined to the shared SMTP address space is interpreted as an attempt to relay. In this situation, Exchange does not accept the incoming e-mail. Additionally, you must specify a server to which Exchange will forward unresolved e-mail. You can specify this destination server by using its host name or by using its IP address.

Perform the following steps to create the SMTP connector.

  • In Exchange System Manager, right-click Connectors, point to New, and then click SMTP Connector.

  • In the Properties dialog box, type a name for the new connector in the Name box.
  • Click Forward all mail through this connector to the following smart hosts, and then type the host name of the destination computer or the IP address of the destination computer. You must type square brackets ([ ]) around the IP address. For example, if the IP address of the destination computer is 192.168.1.10, type [192.168.1.10]. In this lab the destination smart host is Ex2010.destination.local. Hostnames do not require brackets around the name.

    This computer will receive all e-mail that is not resolved to objects in Active Directory.

  • Click Add, click an Exchange server in the Add Bridgehead dialog box, and then click OK.

  • Click the Address Space tab, click Add, click SMTP in the Add Address Space dialog box, and then click OK
  • In the Internet Address Space Properties dialog box, type the shared SMTP address space in the E-mail domain box. When you type the shared SMTP address space, do not include the at (@) symbol. For example, type example.com in the E-mail domain box. Then, click OK. In the lab environment we added contoso.com.
  • Click to select the Allow messages to be relayed to these domains check box. Because Exchange must also receive messages for the shared e-mail address space, you must let Exchange relay messages to this domain. This setting let’s all the SMTP virtual servers that are listed under Local bridgeheads on the General tab accept messages for the shared e-mail address space.

  • Click OK.
  • This email will be coming into Exchange 2010 from anonymous. A receive connector needs to be setup on the Exchange 2010 server to allow anonymous emails to come from the IP addresses of the Exchange 2003 servers in the source forests. For information on how to do this please see:

    http://clintboessen.blogspot.com/2009/07/allow-network-applications-to-relay.html

SMTP Namespace sharing is now configured between both Exchange 2003 Active Directory and Exchange 2010 Active Directory forests. There is another method for configuring SMTP Namespace sharing on Exchange 2003. This method involves modifying the SMTP virtual server under “Forward all mail with unresolved recipients to host”.

I do not recommend this method for two reasons.

  • It does not stamp the message header which can result in mail loops.
  • If you have any users accounts in the Exchange 2003 forest with the Exchange attributes associated to the account but no mailbox, whenever a user in the Exchange 2003 forest sends an Exchange enabled user account an NDR will be generated stating “A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator“. It is not smart enough to realise the user does not have a mailbox and to forward it to Exchange 2010. In Exchange users that have Exchange attributes enabled but no mailbox are known as “Mail users” whereas users that have mailboxes are known as “Mailbox users”. There are times you want Mail users and not Mailbox users. When we perform cross-forest mailbox migration the source user account will revert to a “Mail User” and will still contain the Exchange 2003 attributes. These attributes and SMTP email address are important for keeping the GAL (Global Address List) populated in the source domain.

This concludes part two of this three part series. In part three we will be setting up SMTP Namespace Sharing between Exchange 2010 on-premises and Office 365 in the cloud.

Add your comment (1)

Cloud Strategist
Mimecast

Article Tags

,
Previous Posts