David Ruddell

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

Blog Author — Thu, 13 May 2010 20:48:02 GMT

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

Blog Author — Fri, 23 Apr 2010 17:55:30 GMT

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

Blog Author — Fri, 16 Apr 2010 20:19:37 GMT

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

Blog Author — Sat, 06 Mar 2010 00:07:46 GMT

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

Blog Author — Tue, 03 Nov 2009 03:08:44 GMT

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

Blog Author — Mon, 12 Oct 2009 17:03:22 GMT

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:

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:

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.

Sequencing the Custom Actions

Moving forward from here, the most important thing to remember is that the actual Custom Actions are not wrapped in the same type of transaction as the rest of the installer, which means it is imperative that you take care of any rollback on your own. If you do not do this, you could leave the system in a potentially bad state. That being said, other scenarios you might want to consider are Upgrade and Reinstall/Repair. If your Install action is the same for upgrade and repair, you just need to adjust the conditional in the next section; however, if they are different, you will have to create a set for each one like the ones listed above. Once you have laid out the Custom Actions you wish to run, the next piece of the puzzle is to lay out the InstallExecuteSequence. I personally like to keep things in the proper sequence, as it is easier to read and maintain later, so we will actually start with the Uninstall Sequence. For the actions listed above, it will look something like this:

<!-- Uninstall Action Sequence –>
<Custom Action="CAWriteConfigurationFile.Uninstall.Rollback.Command" After=’InstallInitialize’>Installed and REMOVE="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Uninstall.Rollback" After='CAWriteConfigurationFile.Uninstall.Rollback.Command'>Installed and REMOVE="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Uninstall.Command" After='CAWriteConfigurationFile.Uninstall.Rollback'>Installed and REMOVE="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Uninstall" After=’CAWriteConfigurationFile.Uninstall.Command’>Installed and REMOVE="ALL"</Custom>

In the section above, you will notice that the Rollback is scheduled before the actual command. This is very important, as it ensures that the Rollback action gets scheduled before we run the actual command. Otherwise, if the command fails, the Rollback action was never scheduled and any changes made by the command will not be undone. This can leave the system in an unstable state, so it is important you make sure to put these in the correct order. You will also notice in the first line that we are scheduling the Uninstall Sequence to basically start after InstallInitialize. We can actually schedule these actions to run after ProcessComponents, but it must be scheduled before UnpublishComponents if you plan to use an executable dropped by the installer, as UnpublishComponents will make the binary unavailable to use for the Custom Actions. So now that we have the Uninstall Sequence set up, we will look at the Install Sequence:

<!-- Install Action Sequence –>
<Custom Action="CAWriteConfigurationFile.Install.Rollback.Command" After=’PublishProduct’>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Install.Rollback" After='CAWriteConfigurationFile.Install.Rollback.Command'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Install.Command" After='CAWriteConfigurationFile.Install.Rollback'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Install" After=’CAWriteConfigurationFile.Install.Command’>NOT Installed or REINSTALL="ALL"</Custom>

Just as in the Uninstall Sequence, we schedule the Rollback action directly before the command itself to ensure proper rollback. You will also notice that the first part of the Install Sequence happens after PublishProduct, which ensures that the binary we wish to use is available for the Custom Action.

Multiple Managed Custom Actions

The information before this point can actually be found in pieces around the internet, but what I’m about to show you is not. Assume for a moment that we had not one, but 3 or 4 Custom Actions we wish to run using our ConfigurationManager.exe tool. Not only that, but they require us to run them in a particular order. Now we have an interesting case in which to look at. Creating the Custom Actions themselves is simple enough. Following the pattern above will get you on the right path in a few minutes, but to ensuring proper scheduling can be tricky. Let’s say we have 4 actions called CAUpdateVirtualMachineDatabase, CARegisterNonGacComponents, CARegisterNewVirtualizationSnapIn, and CAImportCustomDataCenterManagementPack. Including the CAWriteConfigurationFile action, we have have five, which must run in this order: CARegisterNonGacComponents, CAWriteConfigurationFile, CAUpdateVirtualMachineDatabase, CARegisterNewVirtualizationSnapin, and finally CAImportCustomDataCenterManagementPack, which relies on each of the previous 4 actions in some way. The Install Action Sequence would look something like this:

<!-- Install Action Sequence –>
<Custom Action="CARegisterNonGacComponents.Install.Rollback.Command" After=’PublishProduct’>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CARegisterNonGacComponents.Install.Rollback" After=’CARegisterNonGacComponents.Install.Rollback.Command'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CARegisterNonGacComponents.Install.Command" After=’CARegisterNonGacComponents.Install.Rollback'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CARegisterNonGacComponents.Install" After=’CARegisterNonGacComponents.Install.Command’>NOT Installed or REINSTALL="ALL"</Custom>

<Custom Action="CAWriteConfigurationFile.Install.Rollback.Command" After=’CARegisterNonGacComponents.Install’>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Install.Rollback" After=’CAWriteConfigurationFile.Install.Rollback.Command'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Install.Command" After=’CAWriteConfigurationFile.Install.Rollback'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAWriteConfigurationFile.Install" After=’CAWriteConfigurationFile.Install.Command’>NOT Installed or REINSTALL="ALL"</Custom>

<Custom Action="CAUpdateVirtualMachineDatabase.Install.Rollback.Command" After=’CAWriteConfigurationFile.Install’>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAUpdateVirtualMachineDatabase.Install.Rollback" After=’CAUpdateVirtualMachineDatabase.Install.Rollback.Command'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAUpdateVirtualMachineDatabase.Install.Command" After=’CAUpdateVirtualMachineDatabase.Install.Rollback'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAUpdateVirtualMachineDatabase.Install" After=’CAUpdateVirtualMachineDatabase.Install.Command’>NOT Installed or REINSTALL="ALL"</Custom>

<Custom Action="CARegisterNewVirtualizationSnapin.Install.Rollback.Command" After=’CAUpdateVirtualMachineDatabase.Install’>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CARegisterNewVirtualizationSnapin.Install.Rollback" After=’CARegisterNewVirtualizationSnapin.Install.Rollback.Command'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CARegisterNewVirtualizationSnapin.Install.Command" After=’CARegisterNewVirtualizationSnapin.Install.Rollback'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CARegisterNewVirtualizationSnapin.Install" After=’CARegisterNewVirtualizationSnapin.Install.Command’>NOT Installed or REINSTALL="ALL"</Custom>

<Custom Action="CAImportCustomDataCenterManagementPack.Install.Rollback.Command" After=’CARegisterNewVirtualizationSnapin.Install’>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAImportCustomDataCenterManagementPack.Install.Rollback" After=’CAImportCustomDataCenterManagementPack.Install.Rollback.Command'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAImportCustomDataCenterManagementPack.Install.Command" After=’CAImportCustomDataCenterManagementPack.Install.Rollback'>NOT Installed or REINSTALL="ALL"</Custom>
<Custom Action="CAImportCustomDataCenterManagementPack.Install" After=’CAImportCustomDataCenterManagementPack.Install.Command’>NOT Installed or REINSTALL="ALL"</Custom>

So after looking at the XML above, the problem might seem a little easier to handle. There is one other small issue we need to address: What happens when one of the above acts differently upon repair or upgrade. So let us look at the upgrade scenario, specifically the Database related custom action. If a database is updated, typically we do not want to destroy the data, so we will want to ‘upgrade’ the database with the new fields or tables, etc. The Custom Action blob itself will look exactly like one in the previous section. The above blob will actually look different. We’ll call the upgrade CA CAUpgradeVMDatabase. Here’s how I would fit it in the existing Install Action Sequence:

<Custom Action="CAUpgradeVMDatabase.Upgrade.Rollback.Command" After=’CAWriteConfigurationFile.Install’>Installed and REINSTALL="ALL" and UPGRADEPATH</Custom>
<Custom Action="CAUpgradeVMDatabase.Upgrade.Rollback" After=’CAUpgradeVMDatabase.Upgrade.Rollback.Command'>Installed and REINSTALL="ALL" and UPGRADEPATH</Custom>
<Custom Action="CAUpgradeVMDatabase.Upgrade.Command" After=’CAUpgradeVMDatabase.Upgrade.Rollback'>Installed and REINSTALL="ALL" and UPGRADEPATH</Custom>
<Custom Action="CAUpgradeVMDatabase.Upgrade" After=’CAUpgradeVMDatabase.Upgrade.Command’>Installed and REINSTALL="ALL" and UPGRADEPATH</Custom>

<Custom Action="CAUpdateVirtualMachineDatabase.Install.Rollback.Command" After=’CAUpgradeVMDatabase.Upgrade’>NOT Installed or REINSTALL="ALL" and NOT UPGRADEPATH</Custom>
<Custom Action="CAUpdateVirtualMachineDatabase.Install.Rollback" After=’CAUpdateVirtualMachineDatabase.Install.Rollback.Command'>NOT Installed or REINSTALL="ALL" and NOT UPGRADEPATH</Custom>
<Custom Action="CAUpdateVirtualMachineDatabase.Install.Command" After=’CAUpdateVirtualMachineDatabase.Install.Rollback'>NOT Installed or REINSTALL="ALL" and NOT UPGRADEPATH</Custom>
<Custom Action="CAUpdateVirtualMachineDatabase.Install" After=’CAUpdateVirtualMachineDatabase.Install.Command’>NOT Installed or REINSTALL="ALL" and NOT UPGRADEPATH</Custom>

Dissecting what we have above, you’ll notice that the big difference between the two is the conditions in which they run. The Upgrade CA requires the product to be installed and the REINSTALL and UPGRADEPATH flags to be set. We do this so that we can schedule this single CA in the middle of the installation sequence. Not only does this make it easier to read, but if we only have the one CA that is affected by a major upgrade it doesn’t make much sense to write 4 more Custom Actions for the rest of the install Custom Actions when we can ensure it gets run in the right sequence with the rest of them. On a side note, the UPGRADEPATH property is actually set by a piece of WiX that looks something like this:

This will tell the Custom Action CAUpgradeVMDatabase to run when we are installing on top of a minimum version of 5.6.1. With that being said, you should have all the information you now need to build sequenced managed Custom Actions using WiX. If there is anything I missed, feel free to leave comments or criticisms. Also keep in mind that there are a handful of individuals out there who will recommend against doing what I just showed you, but if you follow the few guidelines I set up, and don’t forget your rollback/uninstall/upgrade/repair actions, you should be able to safely run your managed Custom Actions.

Installing the F5 Management Pack Using the Command Line

Blog Author — Wed, 07 Oct 2009 21:40:37 GMT

To start with, the F5 Networks Management Pack has been able to run from a command prompt since it’s first release. All of the options available through the pretty user interface are actually all available using command line switches/options. There are also a few extra options not available through the standard GUI. I will go a little more in depth with those options, as they will be new to most of you.

First of all, if you open a standard command prompt in Windows, make sure you are running as a local administrator. In Windows 2008, the easiest way to do this is by right-clicking on the “Command Prompt” icon and finding the little blue and yellow shield that says “Run as administrator” (note: you may be prompted for credentials). From here you will want to find and run the F5Networks.ManagementPack.Setup.exe file. My recommendation is to just drag-n-drop the downloaded file directly into the Command Prompt window, where it should automatically drop in the correct path and filename for you. Now you are ready to add your command line options.

You can find a list of all of our supported command line options by visiting our Wiki documentation. The ‘new’ options you should be most interested in are the /logfile, /debuglogging, /passive and /quiet switches. The rest of the options in the table are available through the standard user interface for the installer. Note that if you run setup from the command prompt without the /passive or /quiet flags set, the GUI will still pop up, but now all of the fields will be populated for you to review as you step through the wizard. The Wiki documentation also has a few examples for you to follow for best results. I personally recommend using the /passive option, as it will still give you a visual cue that installation is happening and notify you when it has completed, whereas the /quiet will run asynchronously on the system with no UI or messages of any kind.

The /logfile and /debuglogging options are very useful if you are having problems with setup and wish to troubleshoot why our software package will not install properly. We also would need these logs if we were to help you troubleshoot, so it is a good habit to get into. If you have any problems trying to run setup from a command prompt, feel free to drop by the F5 Management Pack Forums and ask for assistance.

F5 Management Pack v1.4.1.93 Released: Globalization Support!

Blog Author — Wed, 30 Sep 2009 23:23:03 GMT

Greetings everyone. I would like to announce that the latest release of the F5 Networks Management Pack is now available on the downloads page. Direct links are available below:

Download F5 Networks Management Pack v1.4.1.93 x64 Version Now

Download F5 Networks Management Pack v1.4.1.93 x86 Version Now

With this latest release of the Management Pack, we have added globalization support to our software, which allows us to support localized copies of Windows Server 2003 & 2008 R2, SQL Server 2005 SP2 & 2008, and Systems Center Operations Manager 2007 SP1 & R2. While our software support installation into these localized environments, we still do not have a language pack or localized resources. This just means that all dialogs and information will still be in English.

If you have any questions or complaints, feel free to visit our support forum here.

Datacenter Orchestration Scenarios Now Available

Blog Author — Fri, 28 Aug 2009 23:36:12 GMT

For the past couple of months, fellow developer Joel Hendrickson has been working on some fairly impressive data center orchestration demonstration scenarios. These automated demos really show the true potential of the F5 Networks Management Pack when combined with Systems Center Operations Manager (SCOM) and Virtual Machine Manager (VMM).

Joel has combined the technologies above into a series of scripts and recovery actions that automate the process of spinning up and down resources such as web servers, disabling and enabling pool members when put into maintenance mode inside of Ops Manager, and failing over the active member of a redundant F5 pair based on health or statistics, as opposed to network or hardware failure.

Here are the scenarios:

Add / Remove Resource:

Documentation | Add Video | Remove Video

How-To | How-To Video

Maintenance Mode:

Documentation | Video

How-To

Fail-over:

Documentation | Video

How To

Documentation on the scenarios themselves, along with videos and ‘How-To’ tutorials are now available and will continue to be expanded upon in the documentation section of the F5 Networks Management Pack area.