F5 Management Pack v2.1.0.43 Released with App Designer Support for SharePoint 2010

In conjunction with the release of Microsoft SharePoint 2010, the F5 Management Pack team has released v2.1.0.43 of our Management Pack.  Along side this release we are introducing the F5 Application Designer for SharePoint 2010.  This new application designer is actually very similar to the SharePoint 2007 Application Designer released last month, but with the SharePoint 2010 Management Pack helping run the show, a whole new level of visibility and capabilities have become available to the user surrounding a SharePoint deployment.

The Application Designer for SharePoint 2010 has a lot of the same objects and features as the SharePoint 2007 designer, but with the new capabilities of the SharePoint Foundation 2010 Management Pack, we are really able to get the application specific objects we require to make the most sense out of the whole picture.  On the right is a sample diagram of a single SharePoint Server farm with the basic elements of the designer discovered: F5 LTM Virtual Server, F5 LTM Pool Member, SharePoint Server, Operating System, Website, SharePoint Web Application, and the SQL Content Database for the Website and SharePoint Web Application in the diagram.  There is also an object for Hyper-V Virtual Machine if the server discovered is running under Hyper-V and you have the Virtual Machine Manager Management Pack installed.

If you have your SharePoint 2010 deployment up and running and are ready to dive into the wonderful world of F5 Application Designers, then you may find the following fairly useful.  First we have the Wiki documentation for all of our App Designers, but if you scroll down, you will find the SharePoint 2010 specific deployment guide.  Along with the documentation, I have made up a somewhat lengthy tutorial video to help show you how to get things working, as well as walk you through downloading, installing, and modifying the scripts necessary to successfully run our SharePoint designer.  That video can be located here:

 Working with the F5 Application Designer for SharePoint 2010

If you have any additional questions or concerns, feel free to visit our F5 Management Pack Group and post in our forums.

Building a Microsoft SharePoint Server Application with the F5 Networks Management Pack

Shipping along side the F5 Application Designer Packs, there are two typical application extensions as well.  One of these happens to be targeted at Microsoft SharePoint Server 2007.  With this extension pack, it is easy to deploy and monitor your entire SharePoint application including the important pieces of the Big-IP configuration as well.  This Application Designer profile brings together the key components of your SharePoint deployment, including the SharePoint Server objects, SharePoint Application objects, associated websites as well as any Virtual Machines or SQL Server databases you may be using.

Want more? You got it! Not only will this extension pack help you detect and monitor your SharePoint application, it will also walk you through configuring of your Big-IP from scratch.  This even includes creating all of the SharePoint specific profiles, LTM Virtual Server, Pool and Pool Members settings designed to work with your SharePoint deployment.  With minimal effort, you can have your SharePoint app up and running in no time.  The configuration that we deploy for you is based on the Big-IP v9.x and Microsoft Office SharePoint 2007 Deployment Guide.  This guide and others can be found here: F5 Networks Deployment Guides.  Keep in mind that the configuration we deploy is the very basic configuration to get you up and running.  If you wish to tweak the settings to use your Web Accelerator or other Big-IP Modules, you will have to finish those steps manually through the devices Configuration Utility. 

Below are three videos to demonstrate how easy it can be to discover and configure the F5 SharePoint Application Designer.

Demonstration of the F5 Application Designer SharePoint 2007 Pack

Demonstration of the F5 Application Designer SharePoint 2007 Pack With No Big-IP Configuration

How to Setup and Configure the F5 Application Designer SharePoint 2007 Pack

For further information, please visit our Wiki documentation from the following link:  F5 Management Pack Application Designer Wiki Documentation

Working with High-Availability Pairs and the F5 Networks Management Pack

With our latest release of the F5 Networks Management Pack, health visibility and configuration of failover conditions has never been better.  The release includes updates to the existing failover health model which not only allows you to see what your failover peer is, but also allows for synchronization of configuration between the devices and the configuration of software triggered failover.  What does this mean for you?  Well now you have the ability to configure when a device fails over strictly based on the health of the device in question.  Not only that, but with the availability of the peer address property on the device, users now have the flexibility to write their own custom scripts, alerts and failover scenarios based on the health of the failover peer as well.

Health-based failover gives users the ability to choose when a device will automatically fail over to its peer based on a specifically chosen statistic and threshold.  For instance, say the hard drive on your Big-IP is filling up do to enormous log sizes.  Place a threshold value at 15 GB and when the drive space usage breaches the 15 GB mark, the device will automatically fail over to its peer. 

Another new feature in this release is better config-sync handling.  By default, if device redundancy is detected, any configuration changes made on one device will set a warning flag on the peer device, letting you know that the devices may be out of sync.  You can manually reset the state of this monitor or run one of the Synchronize Configuration tasks.  Keep in mind that this only applies to changes made through Operations Manager, not changes made through the built-in Configuration Utility on the Big-IP itself.  This monitor can be turned off if you wish not to receive the warning state for out-of-sync devices.

Here are some video links to demonstrate the new features:

Demonstration of Software Triggered Failover

Demonstration of Object Level Sync

Along with videos showing how to set up and configure the new features to work in your deployment:

Configuring the F5 Management Pack for Software Triggered Failover

Configuring the F5 Management Pack for Object Level Sync

Basic configuration and documentation of these features is also available on our Management Pack Wiki page.

Maintenance Mode Rules for the F5 Networks Management Pack

A few releases ago we included a couple of new rules and new tasks to go with them.  These rules and tasks will help you keep your Pool Members (LTM and GTM) in sync with your applications.  These new rules are disabled by default, but we highly  recommend enabling and integrating them into your deployment and existing distributed applications.  Here is a short tutorial video on how to turn these rules on:

Enabling Maintenance Mode

For reference, the rules are named F5.Rules.DCO.MaintenanceModeSyncLtmPoolMember and F5.Rules.DCO.MaintenanceModeSyncGtmPoolVirtualServer and can be located under the F5 Device Type in the Rules area of the Authoring section of Operations Manager.  By enabling these rules, any time an LTM Pool Member or GTM Pool Member (Virtual Server) is put into maintenance mode, it will also disable the Pool Member within the interval specified in the overrides of the rule.  This is very important if you want to perform maintenance on either the Big-IP or the web server instance and do not want traffic to be sent.  It should also be noted that once you stop maintenance mode, the Pool Members will not be re-enabled automatically.  There are some technical reasons for this, but it boils down to the fact that a Pool Member may have been disabled before maintenance mode was started and we do not want to enable it if it was taken offline for another reason. 

Now with these two new rules, there are also two Tasks associated with the device.  They are named Sync LTM Pool Members Maintenance Mode and Sync GTM Pool Virtual Servers Maintenance Mode.  If you do not want to enable the rules to automatically disable the Pool Members, you can still manually disable any Pool Member in maintenance mode on a device by running the appropriate task. 

The ultimate reason behind including these rules and tasks it to allow greater flexibility with your applications.  By enabling these rules, you can be assured that any Distributed Applications you have created that reference GTM or LTM Pool Members will behave more efficiently.  Perhaps you have an IIS Distributed App that includes the related Virtual Server.  By putting the entire application into maintenance mode, you will also ensure that traffic is not being sent to these servers, potentially causing more headache than necessary.  If you have any questions regarding this feature, feel free to visit the forums here.

Licensing Feature Added to the F5 Networks Management Pack

Licensing and registration has been officially added to the process for downloading and activating the F5 Networks Management Pack software package. While we realize the process may create a minor inconvenience for some people, it will go a long way in helping us support you, the loyal customer, in the future. The information we collect through the process will help give us a clearer picture of the Microsoft Systems Center (Operations Manager, Virtual Machine Manager, etc) environment in which the Management Pack is being installed.

Along with this release, there is new documentation available here: Licensing The F5 Management Pack.  Along with this documentation is a tutorial video on how to proceed through registration and activation: Registration and Licensing of the F5 Networks Management Pack (temporary link).

I highly recommend you follow the instruction on that page and download the latest version of our Management Pack.  If you have any questions, feel free to comment on this blog or visit our forums. 

Windows Installer XML and Managed Custom Actions

For those of you who have every worked with any installer technologies, you probably know how cumbersome it can be to do anything non-conventional.  A lot of the higher ticket installer packages like InstallShield or WISE offer a robust set of options, but still lack the granularity that some installations may require, aside from costing money.  There are a number of decent free options available such as Nullsoft Scriptable Install System (NCSIS), Inno Setup, and Windows Installer XML (WiX).  A lot of simple installations can rely on these free technologies, or even the built in Windows Installer support provided with Visual Studio.  With the F5 Networks Management Pack there are a lot of post installation steps.  This is where WiX came in to save the day.  Without having to learn a new scripting language, or abide by the constraints of the Visual Studio MSI builder, WiX gives us the flexibility to perform all needed post installation steps, while staying in the comfortable setting of XML.  WiX is also built on top of standard MSI technology, which is well documented and supported by the community, and that makes understanding exactly how everything works a lot easier.

I’m not going to go into the basics of WiX because there is already plenty of good documentation on how to get an installer off the ground.  What really interests me ( and unfortunately has very little documentation) is the proper way to set up managed custom actions, and more so, how to cover all of your all installation scenarios and schedule custom actions in sequence with proper rollback.  José Almeida has written a very useful blog, which will actually cover a lot of the same material I am going to cover, so my recommendation is to read through that first, as it is very useful and will cover a large percentage of custom action scenarios you may wish to implement.  Now actually getting a managed Custom Action working in WiX is not too hard.  In fact, it only requires a few lines of XML.  That being said, there is a right way and a wrong way, so while it’s easy, it can also be very complex.  If you plan to have a a large scale installer (20+ components), I’d recommend fragmenting your script at this point into several WiX files so that you can more easily manage your installer down the road.  One such fragment should be your custom actions and as well as the InstallExecuteSequence. 

Creating the Custom Actions

In Jose’s blog post, he uses the installUtilLib as the binary in which to run as the Custom Action.  The reality is that you can use just about any binary.  You may want to embed the binary or perhaps use an executable that is included with the installation package itself.  For the sake of this post, I’m going to ignore a few unwritten rules and go ahead and show you how to perform a custom action using a freshly installed binary.  If you do choose to use an executable, the best way to do this is to implement it as a Quiet Execution Custom Action.  If you are going to use a Quiet CA, you MUST add the following line to your wxs file:

<Binary Id=”wixca” SourceFile=”wixca.dll” />

This line will add the WiX Custom Action binary library so that you can use it as an entry point for your Custom Actions because we want to run our binary quietly, otherwise we will get a cmd window popping up in the middle of install.  So for the sake of this example, we are going to say that there is a binary file being dropped by the installer called ConfigurationManager.exe.  By itself, this executable does not do anything, but with the proper command line arguments, it will actually run the custom actions.  So for one complete custom action we will have something that looks like this:

<CustomAction Id="CAWriteConfigurationFile.Install" Return="check" Execute="deferred" BinaryKey="wixca" DllEntry="CAQuietExec" />
<CustomAction Id="CAWriteConfigurationFile.Install.Command" Property="CAWriteConfigurationFile.Install" Return="check" Value=’”[INSTALLDIR]ConfigurationManager.exe” Action=”WriteConfigFile” Type=”Install”’ />

<CustomAction Id="CAWriteConfigurationFile.Install.Rollback" Return="check" Execute="Rollback" BinaryKey="wixca" DllEntry="CAQuietExec" />
<CustomAction Id="CAWriteConfigurationFile.Install.Rollback.Command" Property="CAWriteConfigurationFile.Install" Return="check" Value=’”[INSTALLDIR]ConfigurationManager.exe” Action=”WriteConfigFile” Type=”Install.Rollback”’ />

 <CustomAction Id="CAWriteConfigurationFile.Uninstall" Return="check" Execute="deferred" BinaryKey="wixca" DllEntry="CAQuietExec" />
<CustomAction Id="CAWriteConfigurationFile.Uninstall.Command" Property="CAWriteConfigurationFile.Uninstall" Return="check" Value=’”[INSTALLDIR]ConfigurationManager.exe” Action=”WriteConfigFile” Type=”Uninstall”’ />

<CustomAction Id="CAWriteConfigurationFile.Uninstall.Rollback" Return="check" Execute="Rollback" BinaryKey="wixca" DllEntry="CAQuietExec" />
<CustomAction Id="CAWriteConfigurationFile.Uninstall.Rollback.Command" Property="CAWriteConfigurationFile.Uninstall.Rollback" Return="check" Value=’”[INSTALLDIR]ConfigurationManager.exe” Action=”WriteConfigFile” Type=”Uninstall.Rollback”’ />

These are the very basic actions you need to implement in order to make this all work properly.  Each pair above represents one piece of the whole custom action, but I will briefly dissect one pair to help give you a better understanding of what is going on. In the first line we have the Id of the Custom Action, which you should name something that makes reading it easier.  Next we have Return, which is set to check so that if the action fails, we know to rollback. Then we have Execute, which is set to deferred, which I will explain in a moment.  The last 2 pieces are the BinaryKey and DllEntry, which are explained on plenty of pages, but basically it’s telling the WiX compiler to use the WiX Custom Action library and call the function CAQuietExec, which will execute the next line’s Value property, which was also purposefully named with a .Command at the end. So in the second line, we have the actual command that CAQuietExec will run.  The Property field MUST be named the same as the Id field of the previous line.  This is important, as it tells the .Command which Custom Action to ‘link’ to.  The last piece of the second line is the Value property, which contains the actual command to run.  In this case, we are running ConfigurationManager.exe and passing it options for Action and Type, which tell it what to do.  It’s useful to handle the executable this way, as it gives us a framework in which to properly implement the Custom Action in all scenarios.  The last note to make is that the Execute property on the Rollback actions are set to Rollback.  This ensures that these commands ONLY run when Rollback has been initiated.