Monthly Archives: October 2013

Rightsizing the page file for Exchange

So while I was away at a jolly last week, Microsoft slipped out some updated page file sizing recommendations. The news was broken here, by Yong Rhee:

http://blogs.technet.com/b/yongrhee/archive/2013/10/23/reading-the-modern-pagefile-sizing-on-64-bit-windows-no-it-s-not-1-5x-the-amount-of-ram.aspx

and the updated guidelines are here:

http://support.microsoft.com/?id=2860880

along with a little more detail to calculate how much you might need here:

http://support.microsoft.com/kb/889654

BUT! Before you go rushing about to check that all your stuff is correct, you need to stop. Will this make any difference for Exchange? Don’t think so. Exchange uses RAM to move i/o away from the disks by stuffing as much of the database as it can manage into cache. If you have a page file larger than your amount of RAM, you run the risk of paging stuff out to disk, and losing the i/o benefit. The chopping and changing may also cause cache deflation, which is a very bad thing (http://technet.microsoft.com/en-us/library/hh344030(v=exchg.140).aspx).

The recommendations remain the same for exchange; RAM+10MB as a max and min is the correct size for a page file. Anything else is plain wrong.

http://technet.microsoft.com/en-us/library/aa996719(v=exchg.150).aspx

for all your other boxes, I suggest you follow this new guidance (unless the application advice is otherwise), but for Exchange best stick to RAM plus 10MB.

Advertisements

Exchange 2010 doesn’t like Rainbow Trout.

I’ve just finished dealing with a case where after applying service pack 2 one of my customers started experiencing frequent mass disconnections. When they examined the event logs they could see that the RPCClientAccessService was frequently crashing with event ID 4999 and a text similar to:

M.E.RpcClientAccess.Service, M.E.D.S.M.F.Enumerator.MoveNext, System.InvalidOperationException,

They are using Riverbed Steelhead WAN optimizers to reduce their bandwidth requirement between branch offices and the main datacentres that house the Exchange servers. Riverbed have an knowledgebase article that explains that whil many things may cause the CAS to experience 4999 events, one of the things may be the riverbed corrupting RPC/MAPI calls. In this instance the way to tell is by running

Protocol mapi skip-copy enable

on the client and server side riverbed devices. This will disable acceleration for a specific RPC operation  type (EcDoRPC Remote OpCode 0x4D – FXSrcCopyTo) of a specific Microsoft RPC Operation (RPC OpNum 0x2 – EcDoRpc), which is used by some Microsoft Outlook plug-ins. It doesn’t disable ALL the MAPI optimisation. It goes on to helpfully reiterate that there are many things that may cause this corruption (although I can’t think of any off the top of my head), and that if enabling this command *doesn’t* fix the problem, then you should log a call with PSS. I would link to the article, but I can’t, so you’ll have to ask them for it yourselves – it’s variously recorded as S18158 and S15635, and it’s called Event ID 4999 occurs on exchange CAS server.

So far, so what? This affects a veeery small proportion of people.  Why bother writing about it? Because, dear reader, it highlights a much wider problem. Vendors are not like the Avengers, hanging round on some hovering sky platform with Samuel L Hackson, oiling their muscles. They don’t talk to each other that much, mostly, and when they do it’s like cats in a bag. Microsoft do NOT test Exchange with third party products – it’s up to the third party vendor to join the Technology Adoption Programme, get hold of beta and pre-RTM software and make sure their stuff works as expected. If the vendor can’t or won’t do it – WE are responsible for the service we provide to the customer. WE are responsible for making sure that the stuff we provide and maintain continues to work when we patch it – that might mean we have to ask vendors such as Symantec what effect going to a particular patch level will have on Enterprise Vault, say, or it might mean we just have to bite the bullet, build a lab, and test stuff for ourselves (incidentally, this is a really good reason to keep it simple, stupid). OK, so we just sit on a level that we know works, then? NO, because sooner or later we will run out of vendor support. Microsoft stop supporting SP2 for Exchange 2010 in less than 6 months. After that time anyone wanting to log a call will be told they should be on SP3. And do you know what – they’re right. We should be on SP3*.

We are the guardians of complex heterogeneous environments. It’s time to man up.

*The good news is that once we’re on SP3, that’s likely the last service pack for 2010 – no more major upgrades until 2010 goes end-of-life in 2020. Lovely. Get the deck chairs out.

Exchange BPA is not the only fruit.

So we all love the ExchangeBPA, don’t we? And we all had a bit of a panic when it looked like MS had decided not to bother including one for Exchange 2013, yes? (the beta of the new exchange 2013 BPA is here, if you missed it). But there are many other analyzers included with Windows 2008 R2 and Windows 2012 (not 2008, though). Here’s a quick pictorial guide on how to run them, and get output in a form that you can use. hopefully.

How to run a Best Practice Analyzer.

In Windows 2008 R2 click the start button and search for server manager:

bpafruitpic1

In windows 2012 you can click the server manager tile in the start screen.

Start servermanager.msc, and navigate to the role you wish to check. Click on “scan this role”:

bpafruitpic2

And in a few minutes, (quite a few, occasionally) you will get your result:

bpafruitpic3

Double clicking an item ,or selecting “properties” with an item highlighted, will bring up further details:

bpafruitpic4

Unfortunately, it is not possible to print out a whole report via the GUI. To do this requires some powershell magic.

 

How to dump BPA output to HTML.

Start powershell with administrator rights by going to start | all programs | administrative tools | windows powershell modules and right clicking to select “Run as administrator”

bpafruitpic5

Type:

import-module ServerManager

Import-module BestPractices

Get-BPAModel

bpafruitpic6

In the example above there is only one role installed that has a BPA option.

To run the BPA type invoke-BPAModel <model id>

bpafruitpic7

To convert the output to HTML type Get-BPAResult –BestPracticesModelId <model id> | ConvertTo-Html –As List –CssUri$env:windir\system32\WindowsPowerShell\v1.0\Modules\BestPractices\BestPracticesReportFormat.css >  <path to HTML report file>

bpafruitpic8

Note this is all one line, there is a  space between –CssURI and $env and there is a “>” between the path to the .css file and the output filename.

The output should look something like this:

bpafruitpic9

A little playing around would produce a script that could be run once every month or so with task scheduler, that would email the resulting html file to you.

There a lots of other things you can do with BPA here:

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

Why doesn’t webready work the way I want it to?

It will come as no surprise that there are different ways of accessing your mailbox available – some, like outlook anywhere and “classic” outlook, require some level of corporate control over the client device, and some, such as OWA, don’t. if you know your URL and your username/password, you can get your mail anywhere in the world, with OWA. At home. In the pub. In a BoHo café in New York, if that’s your bag.

The trouble with the latter method is that it becomes very easy for the more relaxed user to leave confidential material lying around in the internet cafes and bookstores of the world. Luckily, there’s something you can do about it. By combining the “direct file access” and “Web ready document viewing” settings of the OWA virtual directory you should be able to prevent people downloading documents onto the local machine while they arestill able to view the contents. But there is a little snag. In theory, it should work with JUST the exchange management console settings… disable direct access, enable web ready, force web ready… should do it. Doesn’t.

 

When you set direct file access in the EMC:

webready1

 

You’re not completely disabling direct file access:

webready2

 

So, if you choose to tell OWA you’re on a private computer when you’re actually on a public computer you get this:

webready3

 

When you should get this:

webready4

If you missed the subtle difference, the file is greyed out in the lower example… 😀

 

But who the hell would do that? Well, users will.

“oh, I can’t download this file…” says Carl the service delivery executive to his colleague…

“just log out, and log back in using the ‘this is a private computer’ setting, silly. It’ll work fine”

Moral of this story – use the shell.

webready5

And the filename is greyed out. Hoorah. I’ll not put a picture – imagine one that looks just like the one above. It’s easier.

 

 

Does it stop me sending documents? No.

webready6

 

It just prevents me viewing them:

webready7