Thursday, February 2, 2012
Quick tip: Are you receiving Access Denied messages when you are attempting to run the
Enable-PSRemoting cmdlet? I’ve received them on machines connected to a domain, even when I’m running in an elevated PowerShell window. An easy trick is to open a PowerShell window as the built-in administration account on the machine. Not sure why, but for whatever reason, it seems to work!
Thursday, February 2, 2012
Thanks to Oisin Grehan and his Nivot Ink blog for providing the foundation of this post!
VMWare VMNET Adapters Triggering Public Profile for Windows Firewall
I use Oracle’s VirtualBox to run x64 SharePoint virtual machines from my laptop. I’ve also noticed an Unidentified Network in my Windows 7 list of networks. That is caused by VirtualBox’s Host-Only Network Adapter. It wasn’t harming anything at the time so I left it alone.
However, I later attempt to enable PowerShell remoting on my host laptop for work with SharePoint scripting. Upon doing so, I was greeted with the following error message while attempting the Enable-PSRemoting cmdlet:
Set-WSManQuickConfig : WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.
Another helpful error message! That seems easy enough; Windows makes it very easy to modify the settings for each individual network adapter to Private, Work, or Public depending on your personal preference. However, this is not the case with an unidentified network. With an unidentified network, Windows sticks to its Public settings and will not change it.
So can I now not enable PowerShell remoting since I can’t remove the Public designation of VirtualBox’s unidentified network? No! VirtualBox’s Host-Only network isn’t really a true network connection at all. It is an endpoint adapter. Kudos to Oisin Grehan for developing a nice PowerShell script that will solve the issue by telling Windows, via the registry, that the network adapter is an endpoint device and not a true external network connection. This will cause Windows to stop treating the VirtualBox Host-Only adapter as a network and thus remove the unidentified network (and its public designation) from my list of networks. Problem solved! I’ve modified Oisin’s script to account for VirtualBox’s Host-Only instead of VMware adapters.
Note: This script will need to be executed every time VirtualBox is updated because the update will replace the existing adapter and cause the settings in the registry to be lost.
Thursday, January 26, 2012
What a familiar situation: You are debugging a SharePoint solution (or any ASP.NET code) and have Visual Studio attached to IIS. As you are stepping through your code, checking variables and getting a lot done, all of the sudden you are presented with the following message:
The web server process that was being debugged has been terminated by Internet Information Services (IIS). This can be avoided by configuring Application Pool ping settings in IIS. See help for further details.
It typically occurs within two minutes of Visual Studio pausing on a breakpoint. It is possible to extend this timeframe and the error message gives the answer. The reason Visual Studio presents this message is because IIS is forcefully terminating the worker process being debugged. Why? Because IIS (by default) performs health monitoring pings against each of its worker processes to ensure they are still responding. If IIS does not receive a response from the worker process to one of these pings within a given timeframe, IIS forcefully terminates the worker process. When debugging in Visual Studio, the worker process is stopped while Visual Studio is paused on a breakpoint. Therefore, the worker process has no way to respond to a health monitoring ping. Therefore, the worker process gets terminated.
How does one stop this vicious cycle and allow debugging to continue unimpeded? As the error message states, modify the IIS settings for health monitoring pings! To do this on a particular application pool:
On the left in the Connections pane, click Application Pools. The list of all of the application pools in IIS will display in the middle section of the window.
Select the particular application pool used for debugging and click Advanced Settings under Edit Application Settings on the right in the Actions pane.
Modify the two Ping settings: Ping Maximum Response Time (seconds) and Ping Period (seconds). The Ping Period is the interval used by IIS to ping the worker process. The Ping Maximum Response Time is the amount of time IIS will wait for a ping response. If IIS doesn't get a response after the maximum response time has elapsed, that is when the termination occurs. By default, the ping period is 30 seconds and the maximum response time in 90 seconds. These are great in normal situations, but only give you about two minutes for debugging! Therefore, I would suggest throwing a few extra zeros in there - I personally set my ping period to 3000 seconds (50 minutes) and my maximum response time to 9000 seconds (150 minutes or 2.5 hours). Those values give me plenty of time to debug without needing to worry about termination. Once you have modified these values, click OK.
While I would recommend developers to modify the health monitoring ping settings on their local development servers, these modifications should never be made in a testing or production environment.
Wednesday, November 2, 2011
This article’s purpose is to discuss the best practices around managing customizations to ASP.NET’s Browser Definitions. For more details around ASP.NET’s browser definition platform, please see the Browser Definition File Schema (browsers element) article on MSDN. A quick overview of ASP.NET Browser Definitions can be found in the box below.
ASP.NET Browser Definition Overview
In any IIS site, including SharePoint sites, Microsoft provides a highly configurable platform for defining the various capabilities and mobile adapters of a browser. To facilitate this, Microsoft uses what is called a Browser Definition File which is an XML-based file that defines browsers, what makes that browsers different from the rest (the Identification), and browser properties - capabilities and mobile adapters. Microsoft provides several definition files out-of-the-box with ASP.NET that define various browsers. Then, individual web applications can provide their own Browser Definition Files that will supplement or override the out-of-the-box files. ASP.NET uses this information to tailor page rendering based on the browser making the page request.
ASP.NET allows for multiple files that all have the same schema. There are two sets of files that ASP.NET parses:
App_Browsersdirectory within the web application's web root folder (e.g.
Each individual browser is defined using a
<browser> tag. Within this tag, there are several other allowed tags that define how a browser is uniquely identified and what unique attributes should be defined for that browser. Browser definitions follow an inheritance hierarchy. New definitions must define a parent definition or existing definitions can be modified using the definition's ID.
ASP.NET loads each browser definition file by concatenating them - each browser file contains a series of browser tags. The predefined files are processed first based on the ASP.NET version being used followed by the application-level files. Within each file location, ASP.NET seemingly processes each file in alphabetical order by file name. This means that if there are multiple definitions for the same browser, it seems that the definition in the last file will take precedence.
SharePoint chose to implement two browser definition files that are deployed locally to each SharePoint web application’s
App_Browsers directory. This is important as SharePoint deploys its custom browser definitions in the same way that other applications using SharePoint or ASP.NET should deploy them - as separate .browser files deployed to the application-level
App_Browsers directory. These two files, which may look familiar, are:
compat.moss.browser(If using SharePoint Server editions)
As the Browser Definition File Schema article in MSDN stresses, the predefined files that ship with the .NET Framework should never be modified - ever! This is because they could be overwritten by updates, patches, or service packs; causing any customizations to be lost.
As an extension to this rule, never modify the application-level browser definition files that ship with SharePoint. Why? The same reason as with the predefined files. Future SharePoint updates, patches, or service packs could overwrite these files; causing any customizations to be lost.
So what is left if customizations are required? Thanks to the architecture of these browser definition files, Microsoft allows an application to define its own browser definition files. This is relatively straightforward, but it does require knowledge of the browser definition files you will be overriding. I will cover three scenarios:
As far as I know, there is no way to remove a browser definition. However, I’m not sure there would be a need or desire to do so.
Adding an entirely new browser definition
To add a new browser definition, add the definition’s browser element to a new browser definition file. Deploy this file locally into each web application’s
App_Browsers folder. This new file’s definition(s) will be combined with the other predefined and application-level definitions.
Appending information to an existing browser definition
To append capabilities, mobile adapters, or other information to an existing browser definition, add a new browser tag to a new browser definition file that uses refID to reference the existing browser’s ID. Add the new information within this browser tag. This definition will be combined with the existing browser’s definition, which could be in another file, and append the new information.
Modifying an existing browser definition
To modify a capability, mobile adapter, or other information already defined as part of an existing browser definition, there are a few options. The first would be to use a similar process to appending information. It is possible to define browser definitions in a new file, using refID to reference the existing browser’s ID, and define the same information with different values. The second would be to implement a new browser, with no additional identification, with the parent browser set to the browser that should be modified.
For example, if the IE browser should be modified to be treated as a mobile device, then the following browser definitions could be used:
<capability name="isMobileDevice" value="true" />
<browser id="ieMobile" parentID="ie">
<capability name="isMobileDevice" value="true" />
However, note that if multiple browser definitions exist that reference the same browser ID and each has a different definition of the same information, then the last definition in the last file alphabetically in the application-level will be used.
For example, assume Option 1 was implemented in both
MyApp2.browser and that each of those browser files was deployed to the application-level
App_Browsers folder. MyApp1 defines IsMobileDevice=True and MyApp2 defines IsMobileDevice=False. Since MyApp2 comes last alphabetically, it will take precedence and IsMobileDevice will be False. This underscores the need for applications to consider the environment’s existing customizations when developing custom browser definitions. In this example, the MyApp2 team, presumably deploying after MyApp1, should have seen MyApp1’s existing customization and implemented a new child browser (Option 2) to avoid a conflict or change MyApp1’s customization. The MyApp2 team would need to be aware that either way that is chosen for implementation will affect the entire web application, so they should consult the MyApp1 team!
To properly manage customizations to the browser definitions that ship with ASP.NET and SharePoint, applications being deployed to a SharePoint environment should make use of their own browser definition files that are deployed to the application-level
App_Browsers folder. However, if the environment is planning on host multiple sets of customizations or applications that will require changes to the browser definitions, I would encourage a single file for each web application to ensure that applications changes are developed properly and do not conflict with each other.
Never modify any browser definition file not directly managed by the application being deployed. To implement the changes to existing browsers within the application browser definition files, it is best to use the refID attribute of the browser tag.
When deploying, changes to the
App_Browsers folder should automatically be picked up by IIS and not require any sort of application pool recycle or IISReset.
Wednesday, September 7, 2011
This post is a follow up to a post I wrote a few months ago around triggering a warm up script for SharePoint to execute only when a specific application pool is recycled. You may want to read that post before this one: “Application Pool”-Specific Warm Up Scripts
After using what I recommended in the previous post, I realized there were still issues with this approach. To step back and explain the larger picture, I had a scenario where I needed to execute a warm up script whenever the application pool was freshly started. The script is responsible for filling application-level cache. Therefore, I want to execute the script any time the application pool will be freshly started. This means not just when it is recycled, but also in instances like server reboots. I have previously described how to do this using the Windows Task Scheduler to trigger the script to execute based on certain events being logged.
As it would be too difficult to trigger when the application pool is started (see the Preface above), I needed to continue triggering the event based on what would occur immediately prior to the application pool being started. I found three things that need to be used:
Whenever the server is started, one may wish to trigger the warm up script. If the server will take requests or the script will perform a function desired soon after the server is started, then this trigger can be used. Fortunately, the Windows Task Scheduler allows one to add a trigger that will begin the task At startup. Therefore, one can easily add this trigger!
Whenever IIS is reset, then all of the application pools will be shut down. If requests will come shortly after resetting IIS, it would make sense to use this as a trigger for the warm up script. After analyzing all of the events that the IISreset utility could log, the only one that applies to the situation of needing to track the application pool’s pending start would be when IIS is freshly started: ID 3201. All of the other events described above pertain to states where the warm up script would not need to be executed.
To add event 3201 as a trigger to the task scheduler, you can use the following settings:
Note that, per the TechNet links below, Microsoft no longer supports using the IISreset utility in IIS 7.0 & 7.5.
IISreset Event Reference for Windows Server 2008 / IIS 7.0
IISreset Event Reference for Windows Server 2008 R2 / IIS 7.5
Application Pool Recycle
This is the key event that need to be tracked. The application pool’s recycle settings in IIS are quite extensive! Each reason for recycling produces a different event. This is the major area I realized that I was lacking from the previous post.
IIS logs an event when the application pool recycles
Parameters for automatic recycles can be configured in the IIS Manager. After considering each event, if the warm up script needs to perform any function that should always be in place while the application pool is running, then each of these events should have a trigger set against it.
The good news is that we can use the notion from the previous post to configure the trigger. (“Application Pool”-Specific Warm Up Scripts) One simply needs to include all of the extra IDs in the event filter.
Example Event Filter for an example application pool SharePoint - 32767
Don’t forget to replace SharePoint - 32767 with your application pool’s name!
Important Note: There are also settings in IIS to control if IIS generates recycle event log entries for each of the events listed above! For any warm up script triggers to function properly, ensure that all of the scnearios are set to generate events!
Application Pool Recycling Event Reference for Windows Server 2008 / IIS 7.0
Application Pool Recycling Event Reference for Windows Server 2008 R2 / IIS 7.5
In closing, don’t forget to include any necessary triggers to your own particular warm up script’s scheduled task in Windows so that it executes whenever desired! My suggestions are to include the server start/reboot, the IIS Reset event (3201), and the application pool recycle events (5074-5081, 5117, & 5186).
Thanks to Greg Rosati for providing the links to the event information on TechNet that led to the creation of this follow up post!