Archive for BPA

Srv.sys warning on Windows 2012 R2 Best Practices Analyzer

Sometimes we freak out over every warning message that is displayed when we run Microsoft’s Best Practices Analyzer (BPA). In setting up a new Windows 2012 R2 server recently , BPA displayed a single warning:

Srv.sys should be set to start on demand

The BPA simply says that “Client computers will not be able to access file shares …”


The BPA simply says that “Client computers will not be able to access file shares …”

Wow, that sounds more like a major error waiting to happen! Why, then, is it just a warning? 

The answer is that SMB 1.0 protocol is not on by default for Windows Server 2012 R2. SMB 1.0 is required for Windows XP workstations to access file shares.

So you can safely ignore this error.

But, in the chance that you need the SMB 1.0 protocol running, you can do so very easily by opening an elevated command prompt on the server and typing in this command:

sc config srv start=demand

More information is included in this Microsoft Technet article:

Use psconfig to to resolve SharePoint warnings in SBS 2011 BPA

After installing a SharePoint update to your SBS 2011 server, you may see one (or both) of the following warnings the next time you run the SBS Best Practices Analyzer (BPA) utility:

Use psconfig.exe to upgrade one or more SharePoint databases (Source: 348)

Use psconfig.exe to upgrade SharePoint (Source: 349)

  To resolve these warnings, it will be necessary for you to manually run the psconfig command, as it is not run automatically after an update has been applied.

  1. Open an Administrative command prompt
  2. Change directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN
  3. Run PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures

Please note: it may take some time for the psconfig command to complete. And, in some cases, if you get any errors, it is recommended to run the above psconfig command again.

       image   image

After this, please check that your SharePoint sites are working properly, and rerun BPA to confirm that the warning messages have been cleared.

For more information on this, please check out the following two posts from the Official blog for Windows Server Essentials and Small Business Server support:

SBS 2011 No DNS Name Server Records

If you run the SBS 2011 Best Practices Analyzer (BPA), you may see the following warning:

No DNS name server records.
Source: 74
Issue: There are no DNS name server (NS) resource records for the delegated _msdcs forward lookup zone.

Well, that’s nice. But you may ask yourself: What does this mean? Why did it happen? and Do I need to fix it?

The short answer is that this often occurs as a result of doing a migration to SBS 2011. If your SBS 2011 server is a standalone server (not in a multi DC environment), then it’s not a big concern. You could probably just click on “Exclude this Result” to hide/ignore the warning from appearing when you run future BPA reports.


But if you’re like me, you want to resolve the issue, if possible, instead of just ignoring it.

The warning is caused by the fact that BPA is looking for a _msdcs sub zone under your domain.local zone in DNS. Here’s an example where it is missing:


An excellent tutorial on resolving this issue in detail is available on the Official Windows Server Essentials and Small Business Server Blog site. It also covers the situation where the _msdcs.domain.local zone is missing.

In my case, I already have a separate _msdcs.domain.local zone. So all that  I need to do is to manually create the _msdcs zone and restart the Netlogon service. So, let’s get to work:

  • Right click on your domain.local zone and select New Delegation, then click Next
  • Type in _msdcs for the delegated domain name, and click Next
  • Click Add, and then enter either the FQDN of your server (sbs1.kwsupport.local in my case) and click Resolve, or you can just enter your server’s IP address.
  • In either case, once you have created the new zone, and finished, you will see the new _msdcs zone listed
  • Finally, open up Services.msc and click to restart the Netlogon service, and you’re done.

Rerun the BPA and you will see that this warning message no longer appears!

Hope this helps you!

SBS 2011 DNS parameter MaxCacheTTL is not set

Running the Best Practices Analyzer for your SBS server is highly recommended. After addressing any critical errors, you may find yourself wanting to understand and clean up some of the warnings that may be identified by running BPA.

One such warning is this one:

The DNS parameter MaxCachetTL is not set
Source: 58
Issue: The DNS parameter MaxCacheTTL is not set

The reason for this warning is that there have been some identified cases where name resolution of some top level domains (such as .cn, .br, or will fail. This failure happens if you are using root hints for name resolution in your DNS server. And, by default, both SBS 2008 and SBS 2011 come configured with root hints by default.

Note: this problem with certain top level domains does not occurs if you are using DNS Forwarders for Internet name resolution.

Microsoft has a KB article on this issue and its resolution (KB 968372).

Before proceeding, I am going to completely ignore the “which is better – root hints or DNS Forwarders” argument. Do your own Bing searches on that topic and happy reading for a few days! Here’s one such link: Which is best, root hints or DNS Forwarders – Please Vote!

Let’s address this issue with three questions and answers:

Question #1: What if I don’t know if I am using Root Hints or Forwarders?

  • Open up DNS Manager, click on DNS in the left frame, right click on your server in the right frame, and click Properties.
  • Click on the Forwarders tab.  If there is nothing listed, then you are NOT using DNS forwarders
  • Click on the Root Hints tab. If you are using Root Hints, then this should be populated with a list of IP addresses, like this:


Question #2: If I am using Forwarders, what do I need to do to make this warning message go away?

  • With your BPA Reports page on display, click on the DNS parameter MaxCacheTTL warning to display details about the warning message
  • Click on Exclude this Result


Question #3: If I am using root hints, what do I do to resolve this issue?

To resolve this issue, we will need to add a new registry key and set the MaxCacheTTL to 2 days.

  • Start Registry Editor
  • Drill down to HKLM –> System –> CurrentControlSet –> Services –> DNS –> Parameters
  • Right click on Parameters, click New –> DWORD (32-bit)
  • Enter MaxCacheTTL as the New Value, and press Enter
  • Double click on the MaxCacheTTL key, and change the value to 0x2A300 (Hexadecimal) or 172800 (decimal), then click OK
  • Exit the registry and restart the DNS Server service.

Rerun BPA and the MaxCacheTTL warning should be gone!

SBS 2011 MaxMessageSize Warnings in BPA

If you run the Best Practices analyzer (BPA) on your SBS 2011 server, two warning messages about a conflict in the MaxMessageSize between the Exchange Transport and the Exchange Send/Receive Connectors. Here’s what the BPA warnings look like:


And if you click on each of them, you will see a detail view:

image  image

Since they are only warnings, you could simply ignore it by clicking on the “Exclude the Result” button for each. But, fixing these warnings is a fairly simple process. More importantly, fixing them will get you better acquainted with Exchange PowerShell. Oh, and one final note: these same commands will work on an SBS 2008 server.

So, let’s get going!

Step 1: Start up Exchange PowerShell

Click Start –> Microsoft Exchange Server 2010 –> Exchange Management Shell


Give it a few moments to initialize. Once done you will have a black window with a command prompt.
Looks pretty much like the DOS Command Prompt window, doesn’t it?


Step 2: View current settings

Now we need to type in three PowerShell commands in order to view the current MaxMessageSize values:

  • get-receiveconnector | ft name, maxmessagesize
  • get-sendconnector | ft name, maxmessagesize
  • get-transportconfig | ft maxsendsize, maxreceivesize

Note: the symbol before ft is commonly called the pipeline (|) symbol.
It’s located on the backslash (\) key on most keyboards.

Here’s the result of those three commands on my server:


In my case, my Receive and send connectors were all set to 10MB maxmessagesize, but my transport maxmessagesize was configured as unlimited. So, I had to ask myself: what do I want to change?

Step 3: Change MaxMessageSize settings

I decided that I wanted to change everything to to a 30MB maxmessage size. So, here are the commands to do that:

  • set-transportconfig –maxreceivesize 30MB –maxsendsize 30MB
  • set-sendconnector “Windows SBS Internet Send SBS1” –maxmessagesize 30MB
  • set-receiveconnector –identity “Windows SBS Internet Receive SBS1” –maxmessagesize 30MB
  • set-receiveconnector –identity “Windows SBS Fax Sharepoint Receive SBS1” –maxmessagesize 30MB
  • set-receiveconnector –identity “Default SBS1” –maxmessagesize 30MB

Here’s a screenshot of entering those commands on my server:


Step 4: Verify Changes

Rerun the three commands from Step 2 and verify that all maxmessagesize values match!


Now, rerun BPA and those two warnings should be gone!

Finally, for more information, you may wish to refer to the Microsoft blog post on this same topic.

SBS 2011 BPA Known Issues

Microsoft’s Best Practices Analyzer (BPA) for SBS is an excellent way to identify potential issues that can affect server performance and reliability. Refer to my previous blog post on how to install BPA for SBS 2011 Standard and Essentials.

The BPA report may identify both errors and warnings.

Please keep in mind that some of the warnings are simply that – warnings – and that not every warning needs to be fixed. For example, back in June, Microsoft identified an invalid BPA warning that they posted with a recommendation to ignore the warning. The invalid warning is:

The /EWS virtual directories maxRequestLength doesn’t match the get-transportconfig MaxSendSize

Furthermore, if you attempt to implement the change recommended by this BPA warning, you will create other problems, such as problems when adding a new user (click here).


Installing BPA for SBS 2011

The Microsoft’s Best Practice Analyzer for SBS is one of the first things you should install on any SBS server. For SBS 2011 Standard and SBS 2011 Essentials, this is an easy three step process (which is documented in detail here).

Step 1: First you need to download and install the Microsoft Baseline Configuration Analyzer 2.0. To install this directly on the SBS server, be sure to select the 64 bit version of MBCA 2.0 (File: MBCA_Setup64.msi). Installation takes just a few seconds, literally.



Step 2: Next, download and install the Microsoft Windows SBS 2011 BPA 1.0 to your server (file: BPASetup.msi).


When you install the BPA you have two optional items you may wish to enable (which is the default) or disable:

  • Enable Remote BPA Scan – leave this selected if you plan to run BPA scans of your server from a workstation
  • Integrate BPA with the server console 0 leave this selected if you wish to have the server schedule a daily BPA scan and report the alters on the SBS console.



Step 3: After you have done this, from the same page, download and install the BPA update (File: WSSG-KB2699813-X64-ENU.msp). Please note – when installing this update, you may be surprised o see that you are asked if you wish to Repair or Remove he BPA. Be sure to select “Repair”.


To start your first BPA scan, click Start –> Windows Server Solutions BPA –> Windows Server Solutions Best Practices Analyzer 1.0


Fix RDP Gateway Warning in SBS 2011 BPA

With the UR3 update to the SBS 2011 Best Practices Analyzer, you may see a new warning:

The certificate for the Remote Desktop Gateway service seems to be bound incorrectly
Source: 432


This issue may cause users to not connect to Remote Web Workplace.

The resolution is to run the following commands from an administrator-level command prompt:

REG ADD HKLM\SYSTEM\CurrentControlSet\services\HTTP\Parameters\SslBindingInfo\ /v DefaultFlags /t REG_DWORD /d 1 /f
net stop tsgateway
net start tsgateway

To help you in this process, I have already put these commands into a file for you to use:

  1. Click KB-2472211-RDP-Gateway-Fix.txt to download and save this file
  2. After saving the file, Rename the suffix of the file name from .txt to .bat
  3. Right click on the file, and click to Run as Administrator
  4. I’ve included a pause statement in the file so you can verify that it ran properly


Rerun BPA and the warning message should no longer display.

For more information on this issue, its impact and resolution, please check out Microsoft’s KB 2472211 article.

EDIT: Fixed reference to net start tsgateway. Thanks, Alexander!

Erroneous BPA EWS Warning for SBS 2011

If you are running a SBS 2011 server, after upgrading Best Practices Analyzer (BPA) with UR3,  you may see the following warning message:

The /EWS virtual directories maxRequestLength doesn’t match the get-transportconfig MaxSendSize


This warning is NOT applicable to SBS 2011, and should be ignored!

To ignore this warning and prevent it from showing up again in the future, simply click on the “Exclude this Result” button that is displayed in the BPA for this warning.


However, if you have already performed the resolution steps as recommended in the BPA, just repeat the steps and reset the maxRequestLength to 2097151 (which is 2GB).

For more information, please read the associated blog post on this subject at Microsoft’s Windows Server Essentials and Small Business Server Blog.

BPA Warning of Invalid Server Containers after Migrating to SBS 2011

If you migrated to SBS 2011 from an earlier version of SBS, you may encounter an issue where users are unable to send mail to mail-enabled public folders. If you run the SBS 2011 Best Practices Analyzer, it will report he following warning:

There are empty Servers containers


This issue is easily resolved by using ADSI Edit to remove the empty Servers container. The BPA warning does not give you the specifics on how to do this, so I’ve included some instructions and screen snapshots of the process.

Warning: Using ADSI Edit incorrectly can cause issues with your server. Similar to warnings that you see when using Registry Edit, it is recommended that you have a backup of your server before proceeding.

Step 1: Start up ADSI Edit and access the Configuration connection

  • Start the ADSI Edit utility by clicking Start –> then type: adsiedit.msc and click OK
  • When the ADSI Edit window displays, in the left frame under ADSI Edit, you may only see an entry for “Default naming context [server.domain.local]”.
  • If so, right click on “Default naming context”, and then click Settings. Under the section “Select a well known Naming Context”, click on the drop down box, select Containers and then click OK.
  • Your left frame should now look something like this:

Step 2: Drill down Configuration to CN=Servers

  • Drill down Configuration –> CN=Configuration,DC=domain,DC=local –> CN=Services 
  • Continue drilling down CN=Microsoft Exchange –> CN=domain –> CN=Administrative Groups –> CN=first administrative group
  • Expand CN=Servers and verify that there are no server objects listed
  • Right click on the empty CN=Servers container and click Delete

Rerun BPA and the warning message should no longer display!

For more details on this issue and its resolution, please check out Microsoft’s Windows Server Essentials and Small Business Server Blog site.