Premier Field Engineering

Touch-friendly layouts with Outlook Web App 2013

Premier Field Engineers — Wed, 15 May 2013 23:00:00 GMT

Matt Abraham posts a few top tips on making Exchange 2013’s version of OWA more touch-friendly, simply by modifying the address!

Among his tips are twide (touch, wide) and tnarrow (touch, narrow):

You can modify the Outlook Web App view with a couple of easy switches, which can be saved in your favourites!

The first is designed for your tablet. Just add ?layout=twide to your OWA URL (eg. https://mail.contoso.com/owa/?layout=twide) It will now look like this

Much easier to see on a small screen, and much more finger friendly. Especially when viewed through Modern IE on a Surface/Touch device!.

But what if you are on a phone? Try adding ?layout=tnarrow and you will get the view below (beautifully demonstrated through the WP8 emulator)

Perfect for a mobile OWA wouldn’t you say?

Yes, yes I would. Looks great! Can’t wait for my mail server to make it to Exchange 2013.

There are a few more address-bar nuggets at his post.

Posted by Tristan Kington, MSPFE Editor. Tristan, Tristan, Tristan: you don’t T me no good no more.

TechEd session preview: Troubleshooting Long Boot and High Resource Consumptions

Premier Field Engineers — Wed, 15 May 2013 05:00:00 GMT

TechEd 2013 North America is just around the corner. And if it is TechEd, so is it time for our PFEs to show their deep technical skills coupled with the vital insight into typical customer situations.

Milad Aslaner, our Windows Core SME from Microsoft Germany, has been invited to speak at TechEd – both in North America and later, at TechEd Europe! Milad will show us how to use XPerf v5, from the latest Windows ADK, to troubleshoot slow boot and high resource consumption. In his own words:

If you are attending one of those events please feel free to join and examine how Windows works under the hood, what you need to know when troubleshooting performance issues. I will share some of the lessons learnt when resolving those issues onsite at our customers. Don’t be shy! Ask us what you always wanted to know around Microsoft technologies. The event is for you!

Save the date!

Field Experience: Troubleshooting Long Boot and High Resource Consumptions @ TechEd North America
Date: June 6, 2013 from 1:00PM to 2:15PM | Day 4
New Orleans Theater C (1162) | WCA-B315

Field Experience: Troubleshooting Long Boot and High Resource Consumptions @ TechEd Europe
Date: Date: June 28, 2013 from 2:45PM to 4:00PM | Day 4
Hall 4-2 (500) WCA-B315

Content from Milad Aslaner, posted by MSPFE Editor Arvind Shyamsundar

Exchange 2010: Why does AllowCrossSiteRPCClientAccess revert to false?

Premier Field Engineers — Tue, 14 May 2013 23:00:00 GMT

Exchange 2010 SP2 RU3 and later support the AllowCrossSiteRPCClientAccess capability, and our old Scottish-sounding but Canada-based friend* Rhoderick Milne ran across an interesting mention of it while reviewing disaster recovery operations with one of his customers:

The admins were running:

Set-DatabaseAvailabilityGroup –Identity DAG AllowCrossSiteRPCClientAccess:$True

This was being done as they had noticed in testing (full marks for testing !!) that the AllowCrossSiteRPCClientAccess setting was being changed from $True to $False. To ensure that the DAG was configured as per the design they were running the Set-DAG command to again reset the value for AllowCrossSiteRPCClientAccess.

But why was the setting getting changed?

Sometimes we want to use Set-DatabaseAvailabilityGroup with no additional parameters to:

Remediate incorrect cluster quorum types. Running Set-DatabaseAvailabilityGroup with no other parameters will set the correct quorum type based on the number of nodes in the underlying cluster.

Correct issues with File Share Witness (FSW) folders and permissions. For example if the FSW share is manually removed this will re-create it.

What happens if Set-DatabaseAvailabilityGroup is run to change another aspect of the DAG – would the AllowCrossSiteRPCClientAccess be changed in that scenario? Let’s see…..

I don’t want to spoil it for you, so I’ll let you read the conclusions yourself. (Hint: the guy dies at the end.)

Posted by Tristan Kington, MSPFE Editor, recovering from a bout of sausageitis.

Sharepoint 2013: Configuring Search Service Topology with PowerShell

Premier Field Engineers — Tue, 14 May 2013 11:00:00 GMT

Chandrasekar Natarajan, a PFE based in Canada, runs through some example PowerShell scripts for configuring SharePoint 2013 Search Service applications and topology configuration:

Each Search service application has its own search topology. If you create more than one Search service application in a farm, it’s recommended to allocate dedicated servers for the search topology of each Search service application.

In this blog, we will see how to configure topology for one search service application with multiple search components across 2 servers for redundancy and performance.

Lots of scripts and lots of detail; scripting this type of operation can save you time in the long run. (Or can it? You do the maths!)

Posted by Tristan Kington, MSPFE Editor and recent barbequeue purchaser

AskPFEPlat: How Domain Controllers are found across forest trusts

Premier Field Engineers — Tue, 07 May 2013 23:04:00 GMT

Tom Moser answers a reasonably frequently asked question about cross-organization domain controller location, and shows his work! One key point:

This post is about the a scenario where the subnets in the two forests do not overlap (i.e., client’s IP address from forest A is not covered by any subnet in forest B). This would typically occur in resource forest scenarios with separate networks. For example: federating via trust with Microsoft online services or a trust between a corporate forest and a perimeter forest. Everything you’re about to read below assumes that the client IP from Forest A is not covered by any subnet in Forest B.

(Aside: Overlapping IP ranges is something IP (i.e. The Internet) really wasn’t designed to cope gracefully with. I also had a quick geek-out at how the Hyper-V virtual switch supports mirroring too!

First, let’s talk about how your workstation, or any domain member, finds a domain controller at startup. To demo this, I configured port mirroring on my VMs in Hyper-V and intercepted the entire network conversation on another VM. For the purposes of demonstration, I’ve filtered the traffic to just DNS, LDAP, and Netlogon responses.

)

Detail and commentary are at the original post: How domain controllers are located across trusts.

Posted by Tristan Kington, MSPFE Editor (currently with 800KM more south-ness!)

A Quick Look At System Center Advisor (SCA)

Premier Field Engineers — Thu, 02 May 2013 05:00:00 GMT

Summary: Milad Aslaner, a Microsoft Premier Field Engineer based in Germany, gives us a quick peek at System Center Advisor (SCA), a freely available cloud-based service from Microsoft that enables you to assess your server configurations and proactively avoid problems.

As you probably know by now, my passion is around reliability and performance. I just love to evangelize and engage with customers, partners and colleagues on how to optimize bits and bytes to achieve the best experience.

In this article I want to focus on System Center Advisor, or SCA for short. You can think about SCA as your little friend who proactively warns you if it detects misconfigurations on your server or if it identifies a potential threat. It’s backend is cloud-based and fully utilizes all advantages of Windows Azure. All tests cases are based on Microsoft’s own support data and best practices around configuration, optimization and manageability.

With SCA, we support the following technologies as of this writing: Windows Server, SharePoint Server, Lync Server, Exchange Server and lastly SQL Server workloads. You can download and read more about SCA at www.systemcenteradvisor.com.

So how does it work under the hood?

First you need to specify which servers you want to monitor and which server should communicate with Microsoft. Once you know that, go to www.systemcenteradvisor.com, sign-up and download the toolkit.

The next step is to install the software on your gateway server (i.e. the server which communicates with Microsoft) and add the certificate which is also downloadable from the web interface. Once this is done, you can go ahead and install the agent software on all servers you want to monitor.

Once this is done, the action really starts! After a while your machines will appear in the SCA console and you will start seeing alerts and recommendations.

This should give you a quick look on how to deploy System Center Advisor. Stay tuned for the next blog post on SCA and some lessons learned from the field. Btw, currently the largest organization which utilizes SCA is monitoring over 30.000 servers with this solution!

Written by Milad Aslaner; Posted by Frank Battiston, MSPFE Editor

So You Want To Block Exchange 2010 Autodiscover. Why Would Anyone Do That?

Premier Field Engineers — Wed, 01 May 2013 05:00:00 GMT

Summary: Shamsher Dhanoa, a Microsoft Senior Premier Field Engineer based in the US, tells us why you would want to block the ever-valuable Exchange Autodiscover feature, along with detailed steps and options on how to do it.

Microsoft Exchange Administrators may well remember setting up Outlook profiles and the “Check Names” button, and then came Autodiscover which simplified the Outlook profile creation process. It also does other things like tell Outlook where to go for useful stuff including Free/Busy, Out of Office, and Offline Address Book information. In the screenshot below you can see the result of the Outlook “Test E-Mail AutoConfiguration” task (names have been redacted to protect a corporation that specializes in the procurement of weapons-grade hardware for needy coyotes).

Why would you want to block autodiscover?

So why would anyone want to block all this Autodiscover goodness? I didn’t know but recently found out. It looks like there are a fair number of cross Organization Exchange migrations being done via non-Microsoft migration tools that have a legacy Exchange 2003 mailbox and a new Exchange 2010 mailbox coexisting. An example of this is the Quest Migration Manager for Exchange.

Typically, the legacy and new Exchange Org will be linked by dedicated non-internet routable namespace connectors. For example: @Exchange2010.local and @Exchange2003.local. Every Exchange 2003 mailbox gets an extra e-mail address @Exchange2003.local and, correspondingly, every Exchange 2010 mailbox gets an extra @Exchange2010.local address.

At the start of the migration – Exchange 2010 is populated with pre-created empty mailboxes for everybody - this is the Directory Synchronization phase. The empty mailboxes have their targetAddress attribute populated with the users @Exchange2003.local SMTP address. This means if a message hits Jon’s empty Exchange 2010 mailbox it bounces off to the Exchange 2003 mailbox specified in the targetAddress (Jon@Exchange2003.local). Jon of course has Outlook configured to open his non-migrated Exchange 2003 mailbox.

At any time during the coexistence period there are 2 mailboxes for each user. Non-Migrated users on Exchange 2003 look at the Exchange 2003 Address Book. Migrated users on Exchange 2010 look at the Exchange 2010 Address Book.

When Jon is migrated the targetAddress attribute on Exchange 2010 is cleared and targetAddress on his OLD Exchange 2003 mailbox is populated with Jon@Exchange2010.local. This means when his buddies on Exchange 2003 email him, the message is automatically forwarded through the SMTP connector to his spanking new Exchange 2010 mailbox. If Jon wants to email a non-migrated user he sends mail to the Exchange 2010 mailbox he sees in his Address Book and it redirects via targetAddress to the non-migrated 2003 mailbox.

So what does this have to do with Autodiscover? Nothing yet, but remember there are 2 mailboxes for every user. And Outlook 2010 is pulling towards Exchange 2010 like a beagle to bacon. In 2003 the spacecraft “Beagle 2” was sent to find life on Mars – appropriately it got lost. I had 2 beagles which I also frequently lost. But nevermind, Autodiscover has nothing to do with beagles. However, what if you as an Exchange administrator strolled into the office one Monday morning to find that 10,000 Outlook clients had reconfigured themselves to point to Exchange 2010 and everyone was wondering why their mailboxes were empty?

How to Block Autodiscover

Now we’ve established that sometimes blocking Autodiscover may be a good thing in order to prevent the Monday morning Exchange admin blues, how do we go about blocking it?

Fellow Premier Field Engineer Rhoderick Milne wrote an excellent article on how Autodiscover works here: What Everyone Should Know About Microsoft Exchange Autodiscover.

From this, we see that Outlook will try to use:

1. the SCP record for Autodiscover

2. the standard DNS namespaces:

https://<smtpdomain>/Autodiscover/Autodiscover.xml

https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml

http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml

3. SRV record query for _autodiscover._tcp.<smtpdomain>

We can block this default behavior by deploying the below regkeys:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeSCPLookup = 1
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeHttpRedirect = 1
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeHttpsAutodiscoverDomain = 1
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeHttpsRootDomain = 1
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeSrvRecord = 1

This works great and you can see the results in the Outlook AutoConfiguration test screenshot below.

Registry keys can also be pushed out via GPO, however some environments may not have an established or mature GPO infrastructure, so another solution recommended by some vendors is to place a DENY on the SCP objects in AD and just not publish the DNS records until the migration coexistence is complete. As shown below, this is possible via ADSIEdit (once again please disregard the reference to secretive corporations dedicated to the apprehension of remarkably rapid roadrunners).

An LDAP query as a blocked user will show no Exchange SCP objects returned.

Remember: this is not a Microsoft recommendation but it does appear to work – results may vary, Caveat emptor, contents may settle during shipment, if symptoms persist … and so on.

Now Autodiscover is disabled by all known methods to prevent non migrated clients from flipping their profiles to 2010. But what about migrated Outlook clients?

Migration tools from vendors other than Microsoft typically have a client side agent that will automatically trigger and update the Outlook profile to the new migrated mailbox so that part is good – but what about Autodiscover? Without Autodiscover they may find that Out of Office, free/busy and MailTips are mysteriously malfunctioning, so we need to undo the Autodiscover blockers as soon as users are migrated. Hopefully we have GPOs and can just remove migrated users from a policy to achieve this.

One last note - even with the blockers above in place, a way for Outlook to switch to the new mailbox is the value of the users msExchHomeServerName attribute. Consider the scenario below where an old AD/Exchange 2003 forest is being decommissioned. If Jon’s Exchange 2003 server becomes unavailable at any time, Outlook may try to repair the profile, check the msExchHomeServerName attribute and switch to Exchange 2010.

This can be prevented by using the PreferLocalXML registry key to point to an XML file that in turn hardcodes Outlook to look at Exchange 2003.

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\PreferLocalXML = 1

There is more information on deploying PreferLocalXML on Rhoderick Milne’s blog. There are a few options for blocking Autodiscover. For my particular situation the PreferLocalXML regkey in addition to the regular recommendations of ExcludeSCPLookup, ExcludeHttpsRootDomain, ExcludeHttpsAutoDiscoverDomain, ExcludeHttpRedirect, and ExcludeSrvRecord were necessary.

Written by Shamsher Dhanoa; Posted by Frank Battiston, MSPFE Editor

SQL Server Statistics: Charting Volatile Data And Density Vector Values

Premier Field Engineers — Tue, 30 Apr 2013 05:03:00 GMT

Summary: Tony O'Grady, a Microsoft Premier Field Engineer based in the UK, continues with his second post of 5 advanced articles on charting statistical data with SQL Server. In this post he explores how changes to the underlying data are reflected in cardinality estimations, explores some scenarios, and introduces the concept of density vectors. Enjoy!

In the first post in this series I gave an introduction to how the SQL Server optimiser utilises histogram values for cardinality estimations. In this second post we are going to look at how changes to the underlying data are reflected in cardinality estimations. We will look at specific scenarios where actual values are not represented in the histogram. I introduce the concept of the density vector and show both its advantages and limitations depending on the scenario.

Scenario 1: inserting additional values to [dbo].[SalesOrderDetail_big]

Reviewing the SalesOrderDetailID histogram from the first post, this covered values ranging from 1 – 121317 as we can see in Figure 1:

Figure 1

A sample INSERT statement below adds an additional SalesOrderDetailID value of 121318, inserting 100000 rows for this value. Since the insertion is less than the threshold for an automatic statistics update, the value 121318 will not be represented in the histogram. We can visualise this in Figure 2 which plots the histogram to actual values.

INSERT INTO [dbo].[SalesOrderDetail_big]

           ([SalesOrderID]

           ,[SalesOrderDetailID]

           ,[CarrierTrackingNumber]

           ,[OrderQty]

           ,[ProductID]

           ,[SpecialOfferID]

           ,[UnitPrice]

           ,[UnitPriceDiscount]

           ,[LineTotal]

           ,[rowguid]

           ,[ModifiedDate])

SELECT TOP 100000

            [SalesOrderID]

          ,121318

           ,[CarrierTrackingNumber]

           ,[OrderQty]

           ,[ProductID]

           ,[SpecialOfferID]

           ,[UnitPrice]

           ,[UnitPriceDiscount]

           ,[LineTotal]

           ,[rowguid]

           ,[ModifiedDate]
FROM [sales].[SalesOrderDetail]

Figure 2

When a sample query uses a WHERE clause value equal to 1213818, SQL Server estimates the number of rows as 1. We can see this in Figure 3 where the query plans for this scenario contains an expensive Key Lookup

SELECT * FROM [dbo].[SalesOrderDetail_Big]

WHERE [SalesOrderDetailID] =121318

OPTION (RECOMPILE)

Figure 3

Scenario 2: inserting additional rows for an existing value in [dbo].[SalesOrderDetail_big]

INSERT INTO [dbo].[SalesOrderDetail_big]

           ([SalesOrderID]

           ,[SalesOrderDetailID]

           ,[CarrierTrackingNumber]

           ,[OrderQty]

           ,[ProductID]

           ,[SpecialOfferID]

           ,[UnitPrice]

           ,[UnitPriceDiscount]

           ,[LineTotal]

           ,[rowguid]

           ,[ModifiedDate])

SELECT TOP 91000

            [SalesOrderID]

           ,121317

           ,[CarrierTrackingNumber]

           ,[OrderQty]

           ,[ProductID]

           ,[SpecialOfferID]

           ,[UnitPrice]

           ,[UnitPriceDiscount]

           ,[LineTotal]

           ,[rowguid]

           ,[ModifiedDate]

FROM [sales].[SalesOrderDetail]

Similar to scenario 1 the addition of 91000 rows for SalesOrderDetailID value 121317 is not sufficient to trigger an automatic statistics update. As can be observed in figure 4 the query plan generated for the sample select statement has estimated the out of date statistics histogram value of 10.693

SELECT * FROM [dbo].[SalesOrderDetail_Big]

WHERE [SalesOrderDetailID] =121318

OPTION (RECOMPILE)

Figure 4

Looking at the histogram in Figure 5, for both scenario 1 and scenario 2 a statistics update can resolve the cardinality estimation errors, but managing and coordinating statistics maintenance on a production environment may be difficult to achieve.

Figure 5

Introducing DENSITY VECTOR Values

As in the sample scenario below, when the WHERE clause value is parameterised the optimiser makes use of statistical ALL DENSITY value in its calculations. This value for a column(s) can be reviewed by running:

DBCC SHOW_STATISTICS ([dbo.SalesOrderDetail_Big],[uststs_SalesOrderDetailID] ) WITH DENSITY_VECTOR

Figure 6

One of the advantages of the all density value is that it can continue to be used by the optimiser for cardinality estimations when an insert continues to add additional ever increasing values to a column, as would be the case for an identity column. In effect, for this scenario the all density calculation “keeps up” with the actual values whereas the histogram values do not.

Figure 7

As an example, if we execute the following query the value 121320 returns 10 rows. But, because 121320 is not represented in the histogram, SQL Server estimates 1 row:

SELECT * FROM [dbo].[SalesOrderDetail_Big]

WHERE [SalesOrderDetailID] = 121320

OPTION (RECOMPILE)

Let’s say we run the same query again without a statistics update, but this time parameterising it. In this scenario, SQL Server uses the ALL DENSITY VECTOR value of 11.6564 in its calculation.

DECLARE @x INT

SET @x = 121320

SELECT * FROM [dbo].[SalesOrderDetail_Big]

WHERE [SalesOrderDetailID] =@x

Figure 8

Keep in mind that this approach is not going to benefit all scenarios. Take for example when the WHERE clause value of 121318 from scenario 1 above. In this case the ALL DENSITY VECTOR calculation is 11.6564 and the actual number of rows is 100000. Note this was with fully updated statistics.

DECLARE @x INT

SET @x = 121318

SELECT * FROM [dbo].[SalesOrderDetail_Big]

WHERE [SalesOrderDetailID] =@x

Figure 9

Whereas when we run the same query with a recompile hint this results in an accurate cardinality estimate.

DECLARE @x INT

SET @x = 121318

SELECT * FROM [dbo].[SalesOrderDetail_Big]

WHERE [SalesOrderDetailID] =@x

OPTION (RECOMPILE)

Summary

In this post we looked at how violate data can affect the accuracy of cardinality estimates when the values are not represented in the histogram. We can mitigate for this issue, but the mitigation may not be applicable in all scenarios particularly with outlier values.

In the third post of this series I am going to identify and resolve a scenario where even with a fully updated histogram the values may not be representative resulting in inaccurate cardinality estimations.

Written by Tony O’Grady; Posted by Frank Battiston, MSPFE Editor

Windows Server 2003 Rapidly Approaches End-Of-Life, Watch Out For Performance Bottlenecks

Premier Field Engineers — Mon, 29 Apr 2013 05:06:00 GMT

Summary: Still running Windows Server 2003? Besides making the well-advised recommendation of moving to Windows Server 2012, Frank Plawetzki, a Senior Microsoft Premier Field Engineer based in Germany, runs us through how to monitor servers remotely on a large scale, what to look for from a performance standpoint, and digs into some details on how to properly deal with page and non-paged pool memory to insure these older systems don’t get dinged by memory-hungry applications. Enjoy.

Most IT administrators should be aware that Windows Server 2003 will reach its end-of-life by July 2015. Since Windows Server 2003 has run for so long now and 64-bit/x64-systems are so common nowadays, I did not expect to have to deal with paged-pool and non-paged-pool issues again, but I was wrong.

There are still many customers, who run Windows Server 2003 in production today and many will continue to do so until end-of life of Windows Server 2003 or close to that date for various reasons. While this date is still two years away, current systems should at least be checked to insure things are running properly. In my example here-in, we’ll check that we don’t have 3^rd-party applications depleting paged-pool or non-paged-pool memory since many of those servers are running as 32-bit (x86) installations.

Although Windows Server 2003 is running stably, some 3^rd-party applications today consume large amounts of this paged-pool or non-paged-pool memory which is very limited on x86 systems, Problems start to arise when a x86-System has the /3GB switch set in boot.ini, in order to increase available memory for the application on that server which in fact decreases the amount of available paged-pool or non-paged-pool memory.

Problems may start to arise when 3^rd-party applications have not been developed for the x86 architecture or weren’t optimized for the limited paged- and non-paged-pool memory available on x86-systems.

In my case, one 3^rd-party application was consuming more than 50MB of the total available paged-pool memory of ~150MB. The result was that the affected server stopped working as soon as paged-pool-memory consumption was increased only a little bit more during normal work cycles. As soon as paged-pool (or non-paged-pool) memory is depleted, only a reboot can make the server work again.

This article gives a rough overview, what the /3GB switch does: Exchange memory use and the /3GB switch.

The general architecture of those resources is described here: Pushing the Limits of Windows: Paged and Nonpaged Pool. As you can see from the tables in the latter article, an x86-System in theory should have enough paged-pool or non-paged-pool memory available, i.e. something around 650MB for Windows Server 2003.

Practical operation often shows different values: When you take a x86-system with 4GB RAM as an example, you will usually see a maximum of available paged-pool memory of around 360 MB and a maximum of non-paged-pool memory of around 260 MB. Remember, those limits depend on the used hardware, certain BIOS and software settings, and are calculated during boot time and are fixed until the server gets rebooted.

Sometimes the available paged-pool maximum will even be much less, like in this example:

How to check what amount of paged- or non-paged pool memory is available on a system

The amount of paged- and non-paged-pool memory available on a system (a.k.a. paged- and non-paged MAX) is determined from the hardware, hardware settings like hot-add memory usage, and software settings in the boot.ini and in the registry for memory manager.

You should definitely check your systems for the amount of available paged- and non-paged-pool memory, in order to be sure they are running healthy and can bear a load peak. The link above explains how you can check the practical limits as in the screenshot above, without attaching a debugger for live debugging to the kernel of the running system.

If your servers are equally configured and use the same hardware, those paged- and non-paged-pool memory limits should be identical on your servers. You can then compare the paged- and non-paged-pool memory max with the amount of paged- and non-paged pool currently consumed on your server.

The performance counters for the current consumption that you want to look at are:

“\Memory\Pool Paged Bytes”
“\Memory\Pool Nonpaged Bytes”

You can also quick-check the current consumption via task manager, even on systems where no symbols are deployed.

As soon as the paged- or non-paged-pool memory consumption on your server exceeds 80% of the available memory of this pool, the usage is critically high. At this point, you need to identify which driver or component is consuming what amount of memory. The inbox tool POOLMON helps with that and shows the real-time consumption. For more information on POOLMON see this article: How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kernel mode memory leaks.

Also, with those values, you can create a baseline to get an idea what a healthy memory pattern of a server in your organization looks like during normal production.

How to monitor performance counters on your servers large scale and remotely

You most likely will quickly come to a point where you want to set up a baseline and create a set of performance counters that you want to monitor on all your servers. Windows ships an inbox tool, which makes deploying performance counters on remote systems very easy. The tool is called LOGMAN and can also help query the performance counters which are available on a remote system or extract certain values from a .blg file which is used to save the monitored performance counters to.

As an example, the following command will create a performance counter set on <server> and create a new file as soon as the size limit of 1024 is hit:

Logman create -s <Server> counter MS_Baseline -f bin -max 1 -si 1 -v mmddhhmm -o c:\test\MS_Baseline -cf C:\test\MS_Baseline_Template.txt -cnf 1024

The MS_Baseline_Template.txt file in our example would contain those two entries.

“\Memory\Pool Paged Bytes”

“\Memory\Pool Nonpaged Bytes”

For simplicity, we are only using two performance counters in this example. There are certainly more performance counters you need to look at in order to check whether your server is healthy or not.

After you created the performance counter set on the remote server, you need to start it:

Logman start -s <Server> MS_Baseline.

LOGMAN is a bit tricky regarding the various switches and combination of switches that you can use, so you have to check the syntax carefully and do some tests until the tool creates the pool of performance counters you want, in order to monitor in the exact way you want it to happen, e.g. for the sampling intervals or size of the .blg files. The LOGMAN tool uses performance monitor on the remote system which creates a .blg file that you can open in performance monitor on you client workstation and check the various performance counters.

Summary

If you really still need to run Windows Server 2003, especially the x86-version for some more months, you should at least ensure that the servers are running healthy. You can only achieve that by creating a performance baseline and checking various performance counters.

Microsoft Support or Premier Field engineering is happy to help with questions that you may have around which performance values are important and at what values they should be, according to your workload.

This article wants to point your attention to the fact, that even in times when everybody is running x64-systems, you still have to watch your 32-bit systems carefully for performance. Another (better) way to solve those kind of issues is to migrate to a modern 64-bit operating system like Windows Server 2012.

Written by Frank Plawetzki, Senior Microsoft Premier Field Engineer; Posted by Frank Battiston, MSPFE Editor

A Day In The Life: What does a Microsoft Premier Field Engineer do?

Premier Field Engineers — Fri, 26 Apr 2013 05:00:00 GMT

Summary: Because inquiring minds want to know, Milad Aslaner, a Microsoft Premier Field Engineer based in Germany, provides us some insight into what it’s like to be a Microsoft Premier Field Engineer. Enjoy!

Those who follow my blog posts know that I’m truly in love in what I do. But what is it actually that I do? Typically, when I’m talking with customers sooner or later they ask “Mr. Aslaner what is a Premier Field Engineer?” or “What does your day-to-day job look like?” This is why I decided to give you some insights about my role in this blog post.

Let’s start with the basics: we, as Premier Field Engineers (PFE for short), are part of Microsoft’s Global Business Support group. Each of us are specialized in a specific technology or even a subsegment of it. For example, my primary technology is Windows Client, and I mainly focus on Windows Reliability and Performance. That means I’m a technical expert when it comes to identifying in nanoseconds what’s going on with Windows; how it works under the hood and Windows security features like Mandatory Integrity Control, etc..

We are typically divided into transactional and dedicated PFE’s. Dedicated PFE’s are colleagues who have 1-3 dedicated accounts they’re responsible for and visit frequently. Transactional PFE’s travel around from one customer to the next one, typically changing customers each week. Recently, we also introduced Hybrid PFE’s which is what I’m doing. Hybrid PFE’s are PFE’s who have typically 1-2 dedicated accounts and travel doing transactional-oriented work the rest of the time.

But what is it that we do when we are onsite? We do mainly proactive work which means that we help customers identify ways to improve their IT landscape by delivering several different types of offerings such as workshops, chalk talks, health checks and risk assessments. A smaller portion of our work reactive in nature. This means that once the customer has a critical issue in their infrastructure or when they need a subject-matter-expert on a particular case that we jump in and support them.

Besides working with our valuable customers we are also a lot involved in a bunch of projects like developing new training opportunities, working on “v.Next” projects, blogging on TechNet/MSDN, tweeting about the latest update to our technologies, and, under the umbrella of our “Heroes to Mentors” strategy, we participate in internal and external conferences like TechEd, Premier Nights etc.

In my particular case, I’m a regular speaker at events such as TechEd, TechReady (a Microsoft internal version of TechEd) and Premier Events. I also deliver workshops like Windows 8 New Features and Upgrade as an open delivery which means that usually we invite up to 12 customers to our offices and deliver it there. Besides that, I’m a regular blogger on MSPFE and the German Microsoft Services Blog. Lastly, I’m one of the world-wide Community subject matter experts for Windows Client Deployment, Program Lead for German community readiness in Client Deployment Field, and in a team of world-wide leads for specific Chalk Talks and other Services.

I hope I was able to give you some insights about our every day job and what it’s like to be a PFE (and btw, PFE is recruiting! If you’re interested check out our careers website). PFE Rocks!

Written by Milad Aslaner; Posted by Frank Battiston, MSPFE Editor