Ryan Korock

BIG-IP LTM and Microsoft App-V

Ryan Korock — Fri, 14 Oct 2011 08:19:53 GMT

Over in the DevCentral Microsoft forums there has been quite a bit of noise around deploying BIG-IP LTM to provide load balancing for Microsoft’s Application Virtualization (App-V). Attempting to live up to a commitment I made, here is some guidance on how to configure App-V load balancing using the BIG-IP.

Architecture:

There are several ways to architect the network for App-V, and this is one of the few instances in which F5 advocates the use of deploying with Direct Server Return (also known as DSR or nPath). In traditional load balancing implementations, both incoming client traffic and the return server traffic flow through the load balancer. With DSR, the incoming client traffic flows through the load balancer and to the application server, however the return traffic is routed around the load balancer and sent directly to the client. Since App-V relies on protocols that utilize a simple request in & large stream back model, this architecture has the benefit of eliminating the impact that the large amount of streaming traffic would have on your load balancer.

When implementing DSR, we’re actually using asymmetric routing. Because of this, we need to make a few tweaks to the App-V Server & BIG-IP configurations. We need to let the BIG-IP know that it will only see one-half of the TCP connections, and need to configure the application servers to respond back to the client with the source IP address of the load balancers Virtual IP (VIP), instead of its own IP address. We can force the application servers to do this by binding the VIP address to their loopback adaptors. This step is very important, as without it, the connection will return to the client with destination/source IPs that don’t match the original client connection. For a graphical explanation, take a look at the pic below.

The Client generates the initial connection to the BIG-IP VIP (10.23.218.102)

The BIG-IP then selects an App-V server (10.23.217.12) and forwards the connection to the server.

The App-V server then sends the response to the Client directly through the default gateway router.

It’s important to note that DSR is not required. It’s just a recommended option. You can go with a traditional routed/snat’d configuration with both incoming and outgoing traffic flowing through the load balancer and this will actually work fine. It will actually reduce the complexity a bit (no loopback adaptors needed on the application servers); the only drawback being that you’ll be sending a lot of traffic through the load balancer via the streaming.

If you want to read up on Direct Server Return (nPath) on the BIG-IP, take a look here -> http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_npath.html?sr=17063074

The next portion of this post will focus on the actual configuration. The following assumes a basic understanding of the BIG-IP, and that you have your App-V servers configured as a farm. These instructions cover the load balancing of the APP-V publishing and streaming RTSP(S) services.

APP-V Configuration Notes

1. When you sequence the application, make sure that the hostname for the deployment package is set to the hostname of the load balancer VIP. In my case, I used appvserver.appv.f5demo.net

2. On the App-V servers themselves, make sure that the content path is also refers to the hostname of the VIP. In my case, I used \\appvserver.appv.f5demo.net\content\

3. Ensure that the App-V Servers are added to the Server Group in the Management Console

4. On the App-V client, enter in the hostname of the VIP address as the Publishing Server. In this case, I use appvserver.appv.f5demo.net

App-V Server configuration for Direct Server Return

Now you will need to configure the App-V servers to send response traffic using a source IP that matches the VIP address. If you are using Windows Server 2008, you will need to follow the second step below.

1. Bind the VIP IP address to the loopback adaptor of the App-V servers you are load balancing.

Hint: On Windows 2008 R2, you’ll need to add a loopback adaptor. Use the device manager to ‘add a legacy device’. Select loopback adaptor to install it, and then assign it the same IP that belongs to your BIG-IP VIP.

2. We are effectively asking the App-V server to accept (and send) traffic on an external interface for an IP address that is bound to the loopback adaptor. While this works natively on Windows 2003, Windows 2008 adopted a strong host model (RFC 1122) that prohibits one network interface accepting/sending traffic on behalf of another.

In order to get DSR to work with Windows 2008, you must re-enable the weak host model.Assuming your physical NIC is “Local Area Connection” and your loopback adaptor is “Local Area Connection 2”, to enable weak host you must issue the following

netsh interface ipv4 set interface "Local Area Connection" weakhostreceive=enabled

netsh interface ipv4 set interface "Local Area Connection 2" weakhostreceive=enabled

netsh interface ipv4 set interface "Local Area Connection 2" weakhostsend=enabled

For more details on this, read RFC 1122, or this great article - http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

Now onto the BIG-IP configuration….

BIG-IP Configuration

In our configuration, we will create 3 VIPs, all of which use the same IP address (just different ports). This is the IP that all App-V clients will send their publishing and streaming requests to. This is the IP address that appvserver.appv.f5demo.net resolved to in my example.The 3 VIP/Pools will use the following

Port 332 for RTSPS traffic (or Port 554 if you are using RTSP)

Port 445 for file transfers

Port 0 (all ports) for the RTP/RTCP traffic

A client will initiate the connection via RTSPS or RTSP, but will follow that up with file transfer and RTP/RTCP connections. We will want all of these follow on connections to be sent to the same server that the original connection was sent to. So we will use Source IP persistence for all 3 VIPs, and select ‘persist across services’ so that the persistence is kept across all 3 VIPs.

We will also create a custom fastl4 profile that will assist with the Direct Server Return. By enabling ‘Loose Close’ and upping the Idle Timeout, we cover for the fact BIG-IP only gets to see one side of the TCP connection.

Below are the actual steps needed to take to configure the BIG-IP.

Step 1. Pool Creation

In this step you will create 3 new pools for the 3 different types of traffic we will be load balancing. All 3 pools will have the same App-V server members; they’ll just have different ports assigned to them.

Health Monitors Port 0 : Gateway ICMP

Port 445: TCP

Port 332 or 554: TCP

The graphic below is should match your config if you are using RTSP. If you are using RTSPS you will have a port 332 pool instead of port 554.

Step 2. L4 Profile Creation

For this implementation, you will want to create a custom “Fast L4” profile based upon the original fastL4 parent profile. Name this new profile “appvfastl4” and set the following custom settings

Idle timeout 1800 seconds

Loose Close Enabled

Step 3. Persistence Profile Creation

You will need to create a custom persistence profile based upon the original “source_addr” parent profile. Name this new profile “appv_source_pers” and set the following custom settings

Match Across Services Enabled

Timeout 1800 seconds

Step 4. VIP Creation

Now you will create the 3 VIPs to match up with your 3 Pools. These are standard VIPs with the following custom settings

The VIP type needs to be set to “Performance (Layer 4)”

The Protocol Profile needs to be set to “appvfastl4”

Address Translation option needs to be cleared (disabled)

Port Translation option needs to be cleared (disabled)

The Persistence Profile needs to be set to “appv_source_pers”

Port 0 VIP needs to point to your Port 0 Pool

Port 445 VIP needs to point to your Port 445 Pool

Port 332 VIP needs to point to your Port 332 Pool (if RTSPS used)

Port 554 VIP needs to point to your Port 554 Pool (if RTSP used)

You should be good to go! Test with the client and give it a try!

Troubleshooting:

I plan on adding to this section as I find common setup issues and troubleshooting methods.

One of the common set issues regards the use of SNAT. If you are attempting to use Direct Server Return, SNAT will break DSR. Make sure that no VIP SNAT or Global SNATs are enabled.

One of the best troubleshooting tools is the BIG-IP Pool Statistics Page. If you look at graphic below, you’ll notice a few things

Bits/Packets In counters are incrementing: That means traffic is being sent from the BIG-IP to the App-V servers. Good!

Bits/Packets Out counters are stuck at 0: That means that the BIG-IP is not seeing return traffic. This is also a good thing when using DSR!!

All traffic from our test client is being sent to the .11 node across all the pools. This means persistence is working. Good!!

Future Blog Posts

RTSP Application Layer Monitoring

RTCP/RTP Port Limiting

Non-DSR Implementations

Thanks for putting up with such a long post!! I hope this helps. Please, please send me any updates/omissions/criticism, etc. I will gladly update this post with corrections and additional information.

r.korock@f5.com

The (hopefully) definitive guide to load balancing Lync Edge Servers with a Hardware Load Balancer

Ryan Korock — Thu, 14 Jul 2011 23:59:23 GMT

Having worked on a few large Lync deployments recently, I have realized that there is still a lot of confusion around properly architecting the network for load balancing Lync Edge Servers. Guidance on this subject has changed from OCS 2007 to OCS 2007 R2 and now to Lync Server 2010, and it's important that care is taken while planning the design. It's also important to know that although a certain architecture may seem to work, it could be very far from best practice. I'll explain what I mean by that below.

The main purpose of Edge Services is to allow remote (whether they are corporate, anonymous, federated, etc) users to communicate with other external/internal users and vice versa. If you're looking to extend your Lync deployment to support communication with federated partners, public IM services, remote users and such, then you'll want to make sure you deploy your Edge Servers properly.

This post will discuss some requirements and best practices for deploying Edge Servers, and then we'll go into some suggested architectures. For this discussion, let's assume that there are 3 device types within your DMZ; your firewall, your BIG-IP LTM, and your Lync Edge Server farm.

Requirement 1: Your Edge Servers need at least 2 network interfaces; one or more dedicated to the external network, and one dedicated to the internal. The external and internal interfaces need to be on separate IP networks.

The Edge Server will host 3 separate external services; Access, Web Conferencing, and Audio/Visual (A/V). If you plan on exposing all 3 services for remote users, you have a choice of using one IP for all 3 services on each server and differentiate them by TCP/UDP port value, or go with a separate IP for each service and use standard ports.

Best Practice This is more preference than best practice, but I like to use 3 separate IPs for these services. With alternative ports/port mapping, you can consolidate to a single IP, but unless you have a very specific reason for doing so, its best to stick with 3 separate IPs. You do burn more IPs by doing this, but you'll have to use non-standard ports for certain services if you use a single IP, and this could lead to issues with certain network devices that like certain traffic types on certain ports. Plus, troubleshooting, traffic statistics, logging are all cleaner if you are using 3 separate IPs.

Requirement 2: Traffic that is load balanced to the Lync Edge servers needs to return through the load balancer. In other words, if the hardware load balancer sends traffic to an Edge Server, the return traffic from that Edge Server needs to flow back through the load balancer. There are 2 common ways to ensure that return traffic flows through the load balancer. You can…

Use routing, and have the Edge Servers point to the load balancer as their default gateway.

Enable SNAT on the load balancer, which rewrites the source IP of the connection to a local network address as the traffic passes through the load balancer. In this case, the Edge Servers will believe that a local client generated the connection and send the responses back to that local address.

So there are your two options, which I will refer to as Routing and SNATting. With Routing, your Edge Server will rely on its routing table to route the return traffic out through the load balancer. No obscuring of the source IP address will happen on the load balancer, but you will have to make sure your default gateway & routing tables are correct. With SNATting, you can ensure return traffic goes back through the load balancer and not have to worry about the routing table to take care of this. The drawback to SNATting is that the load balancer will obscure the source IP of the packet as it passes through the load balancer.

I will explain below why the SNAT idea is less than ideal, primarily for A/V traffic.

Best Practice: You can SNAT traffic to the Web Conferencing and Access services on the Edge Server, but do not SNAT traffic to the A/V Edge Services. By obscuring the client's IP Address when using SNAT, you limit the ability for the A/V Services to connect clients directly to each other, and this is important when clients try to set up peer 2 peer communication, such as a phone call. When using SNAT, The A/V services will not see the client's true IP, so the likelihood of the Edge Server being able to orchestrate the 2 clients to communicate directly with each other is reduced to nil. You'll force the A/V services to utilize its fallback method, in which the P2P traffic will actually have to use the A/V server as a proxy between the 2 clients. Now this 'proxy' fallback mode will still happen from time to time even when your not SNATting at the BIG-IP (for example, multiparty calls will always use 'proxy'), but when you can, its best to minimize the times that users have to leverage this fallback method. So even though SNATting connections to the A/V Edge Service will seem to work, it is far from desirable from a network perspective!

FYI - Every load balanced service in a Lync Environment (including Lync FE's, Directors, etc) can be SNAT'ed except for the A/V Edge Service.

Requirement 3: Certain connections will need to be load balanced to the Edge Services, while certain connections will need to be made directly to those Edge Services.

Best Practice: Make sure clients can connect to the Virtual IP(s) that are load balancing the Edge Services, as well as make sure that clients can connect directly to the Edge Servers themselves. Typically users will hit the load balancer on their first incoming connection and get load balanced, but if a user gets invited to a media session that has started on an Edge Server, the invite they receive will point them directly to that server. NAT awareness was built into Lync 2010 to help in environments in which Edge Servers are deployed behind NATs. By enabling the NAT awareness, Edge Servers will refer clients to their respective NAT address in order to route the users in correctly.

Do I need to use routable IPs on the external interface of my Edge Servers? Microsoft says you do, and I would recommend doing so if you can. I have worked on deployments where non-routable IPs are being used (leveraging NATs to allow direct access) and not run into any issues. Just be sure that the Edge Servers are aware of their NAT address.

Best Practice: Suggested Deployment "DNAT in, SNAT out" on the Load Balancer
”DSNAT in, SNAT out” was derived from discussions with a certain MSFT engineer who helped me build this guidance. I’d love to give him credit (he knows Lync networking better than anyone I have ever talked to!!), but if named this person, his/her phone would never stop ringing for architecture guidance !!. Back to the subject, if you keep to "DSNAT in, and SNAT out” for external-side Lync Edge traffic, your deployment will work! It sums it up very well!

So you're ready to architect your Edge Server Deployment. Lets take all the information from above and build a deployment. Keep these things mind…..

External Side of the Edge Servers
Plan for VIPs on your BIG-IP to load balance the 3 external services that your Edge Server Provides (Access, WebConferencing, A/V)
Plan for direct (non-load balanced) access to your Edge Servers by external clients
Plan a method to allow Edge Servers to make outbound connections (forwarding VIP or SNAT on BIG-IP)
Point the Edge Server's Default Gateway to the Self IP of the BIG-IP
Point the BIG-IP's Default Gateway to the Router
Do not SNAT traffic to the A/V Services on the Edge Servers
If you use non-routable IPs on the external Interfaces of the Edge Servers, create a NAT on the BIG-IP for each Edge Server. Make sure the Edge Servers are aware of these NAT addresses so they can hand them out to clients who need to connect directly to Edge Server.

Internal Side of the Edge Servers
Plan for VIPs on your BIG-IP to load balance ports 443, 3478, 5061, and 5062 on the internal interfaces of your Edge Servers
Plan for direct (non-load balanced) access to your Edge Servers
Make sure your Edge Servers have routes to the internal network(s)
You can SNAT traffic to the internal interface of the Edge Servers

I'll leave you with an example of a fully supported configuration (i.e. using routable IP Addresses all around). Keep in mind, this is not the only way to architect this, but if you have the available public IP address space, this will work.

Wow… so much for a short post. I welcome any and all feedback, and I promise to update this post with new information as it comes in. I'll also augment this post with more details & deployments as I find time to write them up, so check back for updates. This may even end up as a guide some day!

Version 1.0 date 7/14/2011

Exchange 2010 with F5 BIG-IP and Dell Article Published

Ryan Korock — Fri, 06 Aug 2010 15:36:02 GMT

Yesterday my esteemed colleague, Fred Johnson, posted a great article on Dell’s Enterprise Technology Center about some joint F5 & Dell testing on Exchange 2010 that recently took place.

There are some architectural changes within the way Exchange 2010 is deployed that make having a hardware load balancer even more critical when trying to scale and provide high availability. This article discusses those changes, discusses the testing that was done, and also goes into depth on the results and finding from the testing. I highly recommend the article for anyone looking at migrating to Exchange 2010.

http://www.delltechcenter.com/page/Exchange+2010+with+F5+BIG-IP+and+Dell

Great job Fred!

F5 and Microsoft BranchCache

Ryan Korock — Tue, 08 Jun 2010 17:41:51 GMT

BranchCache is a technology that Microsoft released with Windows 7 and Server 2008 R2 which can have a profound effect on where users actually source their content and the bandwidth consumed in retrieving that data.

It’s fairly common in today’s work world to see global enterprises have multiple branch offices with users who regularly access data from a single centralized datacenter. If you take a look at the data that these users are commonly requesting, you’ll quickly realize that there is often a significant amount of data that is repetitive between the branch users.

BranchCache is a technology designed to cut down on the unnecessary round trips from the branch office to the datacenter for data. By keeping an accessible copy of the content in the local branch, there will be a significant reduction in bandwidth used, and users will often be able to get the content faster than retrieving it from the distant datacenter.

BIG-IP LTM can provide significant value when deploying BranchCache for HTTP/S in the datacenter. By leveraging the power of our iRules, you can offload the content hash creation to the BIG-IP, allowing your web servers to focus on what they best, serving content. BIG-IP also has the intelligence to optionally cache those hashes, accelerating the solution for subsequent requests.

Into the weeds……..

I wouldn’t dare wrap up this post without a technical discussion on the solution. If you are still reading this, then you’re probably aware of how the basics of BranchCache work. When the initial request from a BranchCache enabled client for the content comes in, the W2008 R2 server will create and send the hash values of the content back instead of actual content. The client can then use these hash values to determine if any local caches already have the content. By enabling the iRule below, the BIG-IP that is sitting in front of your web servers will actually offload that hash creation from your servers by grabbing the content from the servers, creating the hash values and sending them to client.

BIG-IP creates and sends the hash, offloading this costly process from the server
BIG-IP caches those hash values to accelerate subsequent requests
This is all compatible with OneConnect!!
No F5 equipment is needed for this solution in the branch office
This works for HTTP traffic with the hosted and distributed models of BranchCache

Interested in the iRule? Check it out here –>

http://devcentral.f5.com/wiki/default.aspx/iRules/MicrosoftBranchCacheHashOffload.html

As always, feel free to reach out to me with any questions or concerns!

F5 Releases its Unified Access Gateway Deployment Guidance

Ryan Korock — Mon, 04 Jan 2010 07:30:37 GMT

F5 has been working with Microsoft over the last few months on building a solution for using BIG-IP LTM to scale the newly RTM’d Forefront Unified Access Gateway. For those of you who don’t know, UAG is the next evolution in Microsoft’s Internet Access Gateway (IAG) solution, incorporating several well-known and new access methods into one package.

There are a few unique features within UAG which makes the technology compelling. Starting off with it’s broad support of access protocols (SSL, IPSec, Teredo, IPv4, IPv6, etc…) as well as its enhanced management functionality. By building in support for Active Directory and Direct Access, UAG allows security administrators to have granular control over the users and resources.

F5 has developed a great solution for providing scalability, high availability, and performance to UAG. By leveraging the BIG-IP LTM’s application layer health monitoring, advanced load balancing, and intelligent iRules engine, we’ve built a solution that allows UAG to scale to meet the needs and uptime requirements of the enterprise and provider markets.

As a start, F5 has created a landing page for the UAG solution. On that page, you will find a link to our updated BIG-IP LTM Deployment Guide for UAG. We’re continuing our testing with Microsoft, and plan to expand the scope of the current solution to cover more access protocols as well as using BIG-IP GTM to provide global access.

Later this week I’ll blog on some of the technical details regarding the solution. Leveraging iRules to do some of the connection tracking is something that I have a feeling most of the DevCentral community will be very interested in reading about.

F5 at Microsoft Tech·Ed EMEA in Barcelona

Ryan Korock — Wed, 01 Oct 2008 21:46:10 GMT

Just wanted to drop this note and let everyone know that we'll be back in Barcelona for Tech·Ed EMEA as a sponsor this year. We were there last year, and got to meet quite a few partners and customers. Overall, it was a great show, and we look forward to another great event this year.

F5 will have a booth in the exhibitors lounge during the IT Professionals Conference (Nov 3rd-7th), so please drop by and say hello!!

Microsoft Management Summit 2008 (MMS) Recap

Ryan Korock — Fri, 09 May 2008 22:21:57 GMT

Our extended Microsoft Partner Team spent last week in Las Vegas for the Microsoft Management Summit. While a few members of our team attended the sessions & trainings, the rest of us manned the F5 booth. We had a phenomenal turnout, and it was great to meet those of you who stopped by!

There were several highlights from the show. We brought several members from our ControlPoint team, who gave the first public demos of the upcoming product. For those of you who aren't aware of ControlPoint yet, it is our yet-to-be-released F5 monitoring solution that is built upon System Center Operations Manager 2007. The feedback from the demo was extremely positive, with most people ecstatic about the OpsMan platform that we have chosen to go with.

Dan & Jennifer giving a ControlPoint demo

Look Calvin, I'm working!!!

Heavy traffic again this year at the booth

We also introduced our Microsoft centered Virtualization Strategy, which focuses on dynamically provisioning services in the network. We have been working with our friends at HP to build a demo of the solution, and they actually brought a working prototype to MMS to showcase. I really want to discuss our Virtualization strategy in depth, so I'll devote a full post to it in the near future.

Last, but not least, our own Alan Murphy delivered a great presentation on Virtualized Data Centers, which was very well received by those who attended. Like always, Alan hit one out of the park.

Overall, it was a great show for F5. Plus, I came back from Vegas with all my money this time! ;)

For now,
Ryan

Traffic Management & BizTalk 2006

Ryan Korock — Mon, 07 Apr 2008 22:58:19 GMT

What does a business do when they need 2 incompatible systems, such as a purchase order system from vendor X & an invoicing system from vendor Y, to communicate and share information?

One popular option is to implement a business process management (aka, information broker) system like BizTalk from Microsoft. In a very simplistic description, it is designed to take information from one system, manipulate it as necessary, and send it to the requesting system (and vice versa). It's a popular method for enabling data from legacy mainframes to be presented on more modern web based platforms such as SharePoint.

We are currently engaged with the Microsoft BizTalk team in Redmond to develop guidance on "load balancing Biztalk", and should hopefully have some collateral in the form of deployment guides soon. But in the meantime, I wanted to post a link to a great whitepaper our friends at HP released on scaling BizTalk. You'll notice that HP used a BIG-IP as the load balancer to do their performance testing for this paper

http://h20219.www2.hp.com/ERC/downloads/4AA0-9561ENW.pdf

If you get a chance, give the pdf a read. It is a good primer on how BIG-IP can load balance receiver adaptors. We're also working on guidance for XML message security & more that should make for a very compelling solution. Check back soon for more!

Load Balancing Dynamics CRM

Ryan Korock — Thu, 13 Mar 2008 20:03:06 GMT

We’ve been working with the Microsoft Dynamics team for over a year now building and testing a scalable architecture for their CRM package. And now with the release of CRM 4.0, BIG-IP plays a critical role in providing high availability, scalability, and performance for an enterprise deployment.

If you’re interested in deploying BIG-IP with Dynamics CRM, please take a look at the deployment guide here -> Microsoft Dynamics CRM 4.0 Deployment Guide

Just to let you know, we’ve also slated a round of testing for WebAccelerator with Dynamics CRM to happen later this year. We should be able to get some pretty compelling acceleration results from that. I’ll keep you posted on how the progress of that!

For now,
Ryan

Load Balancing Microsoft Office Communications Server 2007

Ryan Korock — Wed, 26 Dec 2007 20:00:10 GMT

I’m not sure how many of you have considered Office Communications Server 2007 (OCS) yet, however the new functionality such as VOIP, Web Conferencing, and Application Sharing are starting to attract some real visibility within the Unified Communications space. In fact, Gartner places Microsoft squarely in the leader’s quadrant for their UC 2007 Magic Quadrant.

http://mediaproducts.gartner.com/reprints/nortel/150273.html

Providing high availability and scalability for an OCS deployment is becoming more and more critical to the enterprises are looking to adopt OCS as part of their communications strategy. Interestingly enough, Microsoft has gone as far as requiring the use of a “hardware load balancer” for enterprise deployments. NLB is not supported in lab or production deployments with OCS.

http://support.microsoft.com/kb/939800

We’ve been working and testing with the OCS product team since the early alpha release days to make sure that we could provide a compatible solution for load balancing OCS. The good news is that we have a rock solid solution, tested by both F5 and Microsoft, and documented here

http://www.f5.com/pdf/deployment-guides/microsoft-ocs-ltm94-dg.pdf

We put over 6 months of testing, documenting, and collaboration with Microsoft in putting this deployment guide together. If you’re looking for architectural strategies, best practices, or even just configuration instructions, take a look, they’re in there.

I’d also like to elicit any feedback on deploying BIG-IP & OCS. My team tends to receive quite a bit of field related experiences on the subject, and our plan is to include this type of feedback in the form of best practice updates to these guides.

HP whitepaper on SharePoint Acceleration using F5 gear

Ryan Korock — Wed, 12 Dec 2007 15:54:58 GMT

A few months back we participated in a round of "best practices" testing surrounding accelerating SharePoint with HP. The results were extremely impressive, and are documented in this whitepaper.

http://h71019.www7.hp.com/ActiveAnswers/library/GetPage.aspx?pageid=570023&statusid=0&audienceid=0&ccid=0&langid=121

The original purpose of this testing was to truly determine if the SharePoint acceleration technologies, specifically the one developed by F5, improved performance enough to be built into HP's suggested architectures. Needless to say, the testing went very well and the results speak for themselves. Take a look!

I happened to be one of the two F5 engineers that were dedicated to this project, and I have to mention that I was very impressed with HP's testing methodologies and practices. Jimi(HP) and his team understand the importance and value of an engagement like this, and put a tremendous amount of effort into making sure the testing was comprehensive, fair, accurate, and conclusive. The overall project took well over 2 months and involved hundreds of different test passes. I tip my hat to all that were involved on their side.

I will hopefully find the time to post some more technical information on the testing & results, however in the meantime I just wanted to write this quick post to announce that the whitepaper is now public!

Welcome to my blog!

Ryan Korock — Thu, 30 Aug 2007 19:24:53 GMT

After having this blog account set up for almost a year, I've actually published my first post!
I've been with F5 nearly 8 years now, working as an engineer in several groups that have spanned Services, Sales, and Marketing. Almost 2 years ago I joined our Microsoft Alliance team as the first dedicated engineer, focusing on bringing some of our joint solutions out of the lab and into production environments.
Within those 2 years I've seen tremendous growth within our Microsoft Partnership. Along with being invited into the Microsoft Global ISV program (which less than 200 partners are members of), we've built new relationships with several groups within MSFT, including Unified Communications, Longhorn, Dynamics, MobileM3, Terminal Services, Commerce Server and more.
Unfortunately, one of our team members, and a fellow engineer, JamesH, has decided to take a new role within F5. James was an incredible contributor to our team, but found a CorpDev position in which he truly will add a huge amount of value to F5. Congrats James, and I wish you the best of luck.
I plan on using this blog as a means to communicate some of the work we're doing with MSFT. We're working on some fantastic new joint solutions, and this will make for a great way to update our customers on the progress we’re making. I hope you enjoy reading it, and feel free to post any feedback.


Dan & Jennifer giving a ControlPoint demo	Look Calvin, I'm working!!!	Heavy traffic again this year at the booth