Skip to content
Oct 20 12

Windows Server 2012: Enabling RDS in the answer file

by rkorock

When building an answer file (autounattended.xml) for an automated deployment of Windows Server 2012 or Windows 8, I often want the new system to automatically have Remote Desktop Services enabled so I can easily connect to it. This really helps for headless installs.

I used Windows System Image Manager (WSIM) to build my answer files, so here are the instructions to using WSIM to enable Remote Desktop in the answer file.

The 2 simple things your answer file needs to do

1. Enable Remote Desktop

2. Modify Windows Firewall

 

1. Enable Remote Desktop:

In the Windows Image pane of WSIM, add the component:amd64_Microsoft-Windows-TerminalServices-LocalSessionManager__neutral to “Pass 4 Specialize”

Then change the fDenyTSConnections from true to false like below

enabling rd

 

2. Modify Windows Firewall

We have to modify Windows Firewall to allow incoming RD requests. Without doing this step, incoming RD requests will be blocked, and you will not be able to connect.

In the Windows Image pane of WSIM, add the component:amd64_Networking-MPSSVC-Svc__neutral to “Pass 4 Specialize

In the Answer File pane of WSIM, expand the newly added MPSSVC component (like below), left-click on FirewallGroups, and select ‘Insert New FirewallGroup

disabling firewall1

 

Once you have the new FirewallGroup, click on it and edit to look like below:

disabling firewall2

Active: true
Group: Remote Desktop
Key:RemoteDesktop
Profile: all (You can set this as desired, but I use ‘all’)

That’s all!, this answer file will now enable RD and the appropriate firewall rules. For reference, here is the finished pieces of the answer file.

Enabling RD

        <component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" name="Microsoft-Windows-TerminalServices-LocalSessionManager" processorarchitecture="amd64" publickeytoken="31bf3856ad364e35" versionscope="nonSxS">
            <fdenytsconnections>false</fdenytsconnections>
        </component>

 

Configuring Firewall Rules

        <component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" name="Networking-MPSSVC-Svc" processorarchitecture="amd64" publickeytoken="31bf3856ad364e35" versionscope="nonSxS">
            <firewallgroups>
                <firewallgroup wcm:action="add" wcm:keyvalue="RemoteDesktop">
                    <active>true</active>
                    <group>Remote Desktop</group>
                    <profile>all</profile>
                </firewallgroup>
            </firewallgroups>
        </component>
Oct 19 12

Windows Server 2012: Setting an IP address in the answer file

by rkorock

I was using the latest version of Windows System Image Manager (WSIM) to build an  an answer file (autounattend.xml) for a Windows Server 2012 deployment and attempting to include the steps necessary to set the network settings (IP address, netmask, and default gateway).

In order to do this, you need to add “wow64_Microsoft-Windows-TCPIP_6.2.9200.16384_neutral_31bf3856ad364e35_nonSxS” to “Pass 4 Specialize”, and configure.

I used WSIM to set the IP address information, and below is the snippet from my answer file that was written out by WSIM.

<interfaces>
	<interface wcm:action="add">
		<ipv4settings>
			<dhcpenabled>false</dhcpenabled>
			<metric>10</metric>
			<routerdiscoveryenabled>false</routerdiscoveryenabled>
		</ipv4settings>
		<unicastipaddresses>
			<ipaddress wcm:action="add" wcm:keyvalue="1">10.23.249.222/24</ipaddress>
		</unicastipaddresses>
		<routes>
			<route wcm:action="add">
				<identifier>1</identifier>
				<metric>10</metric>
				<nexthopaddress>10.23.249.1</nexthopaddress>
				<prefix>0.0.0.0/0</prefix>
			</route>
		</routes>
		<identifier>Ethernet</identifier>
	</interface>
</interfaces>

Using that WSIM generated answer file to boot the new Windows Server 2012 VM, I got the error message below

WSIM.ERROR

“Windows Setup encountered an internal error while loading or searching for an unattend answer file.”

The problem is that the new Windows Server does not like the syntax of the answer file that WSIM created. To resolve the issue, I moved the following line from the bottom of the snippet to just under the “<Interface wcm:action=”add”>” line.

<Identifier>Ethernet</Identifier>

Now the snippet looks more like

<interfaces>
	<interface wcm:action="add">
		<identifier>Ethernet</identifier>
		<ipv4settings>
			<dhcpenabled>false</dhcpenabled>
			<metric>10</metric>
			<routerdiscoveryenabled>false</routerdiscoveryenabled>
		</ipv4settings>
		<unicastipaddresses>
			<ipaddress wcm:action="add" wcm:keyvalue="1">10.23.249.222/24</ipaddress>
		</unicastipaddresses>
		<routes>
			<route wcm:action="add">
				<identifier>1</identifier>
				<metric>10</metric>
				<nexthopaddress>10.23.249.1</nexthopaddress>
				<prefix>0.0.0.0/0</prefix>
			</route>
		</routes>
	</interface>
</interfaces>

 

And it works now!

Oct 10 12

TMG2F5 Series: Publishing Microsoft Exchange Using F5

by rkorock

Although predicted by some, Microsoft caused quite a stir last week by formally announcing the discontinuation of Forefront Threat Management Gateway. One of the primary use cases of TMG has been to externally publish Microsoft applications, and F5 has often co-existed in these environments. With the sunset of the TMG line, it’s time to look at alternative technologies to replace the responsibilities of TMG, and the F5 gear that you already have in the network may be the best solution. I am putting together a 3 part blog series on leveraging F5 as a suitable (dare I say, better?) TMG replacement for your Exchange, Lync, and SharePoint deployments. This is the first post of the series, and will focus on using F5 to securely publish Exchange services.

Architecture

One of the most significant benefits of leveraging F5 to publish Exchange services is the consolidation of devices & simplification of the architecture. Enterprise customers leveraging TMG for publishing applications are often using F5 to provide the traffic management control to the TMG & application services, which means multiple devices and a tiered network. In a traditional F5/TMG deployment, traffic management and security responsibilities have often been split amongst devices like below….

image

As you can see, there are several tiers in the architecture, which leads to complexities in configuration and troubleshooting. By onboarding the publishing responsibilities onto the BIG-IP, customers can simplify the architecture by reducing the network segments and consolidating into an HA pair of BIG-IP devices. And more importantly, all without losing significant functionality.

image

Now that we have a basic understanding of the architectural benefits of using F5, let’s dive deeper into some of the features and functionality that F5 will be providing when being used to publish Exchange Server.

Traffic Management

Yes, TMG does have basic server load balancing capabilities, however this has never been functionality that has met the needs of the enterprise customer. Even in the heyday of TMG, most enterprise customers opted to leverage a 3rd party technology, such as the BIG-IP LTM, to handle this workload. BIG-IP has been designed from the ground up (both hardware and software) to handle traffic management, and honestly, you won’t find similar performance nor features in any other solution. A critical piece of the Exchange network solution is providing high availability and scalability through load balancing, and the BIG-IPs application health awareness & load distribution engines deliver on the promise of making sure users & mail are consistently sent to Exchange servers that are alive and performing optimally. As enterprises move to multi-datacenter Exchange deployments, F5’s Global Traffic Manager (GTM) can provide the same load balancing and resiliency intelligence, but at the wide area level.

Layer 3-7 Firewalling

With roots in the firewall space, TMG has a history of providing layer 3/4 security, and over the last few years Microsoft added in application firewalling as well. BIG-IP LTM, an ICSA certified firewall, is a default-deny platform coupled with an advanced DDOS mitigation engine, making it extremely well suited to provide the layer3/4 defense perimeter. BIG-IP LTM also ships with content inspection & iRules, that allow administrators write basic filters to stop well known application layer attacks. Enterprises looking for a more advanced Web Application Firewall for Exchange can activate the Application Security Module (ASM), which ships with pre-built security policies for Outlook WebApp and ActiveSync.

Server Optimization

I hate to see this significant benefit of the solution overlooked, primarily because of the dividends it pays. Exchange Server makes use of SSL/TLS for a majority of the client access protocols, including Outlook Anywhere, Outlook WebApp, and Activesync. The server CPU cost of negotiating these SSL transactions is significant, and by offloading the SSL responsibilities to the BIG-IP LTM, enterprises can leave their Exchange servers to do what they do best, serve content. BIG-IP LTM also includes TCP optimizations and content caching which can significant decrease the load on the servers. By leveraging the optimization & offloading features in BIG-IP LTM, customers can decrease the load on the servers, allowing them to perform faster, and also possibly allowing them to go with a smaller farm of servers to serve the same amount of users.

Perimeter Security

Let’s face it, exposing domain joined servers (CAS, Hub) to anonymous connections is a bad idea, and this is probably one of the most compelling reasons to put TMG in front of your Exchange architecture. The good news is that F5′s Access Policy Manager (APM), which is a software module for BIG-IP LTM, can provide an enhanced perimeter of security by making sure no user or connection reaches the CAS server until it has been authenticated and authorized. The APM engine is incredibly powerful and flexible, and new customer use cases are brought to our attention constantly. Client side certificate support, AD FS integration, client interrogation, single sign on, Active Directory attribute enforcement, are all features that APM supports in making sure the right level of privileges are granted the users that are authenticated before being sent to the CAS services. The Active Directory awareness that APM also provides has been instrumental in helping enterprises seamlessly upgrade from Exchange 2007 to Exchange 2010 without making any client side modifications at all.

Acceleration

Native BIG-IP LTM includes a set of acceleration technologies, such as caching and compression that provide benefit for Exchange deployments. Enterprises have the option of going a step further and leveraging advanced acceleration of Exchange by enabling the WebAccelerater Module (WAM) on top of their BIG-IP LTM to reach new levels of performance. WAM provides a set of acceleration technologies, such as browser optimization, deduplication & intelligent client side caching that enterprises with a large remote workforce, or multiple branch offices will want to take a look at.

Administration

10+ network and access protocols can make it a challenge to deploy Exchange with the network optimally configured. Many of these protocols have different persistence, security, and acceleration profiles, and a configuration that may end up ‘working’ is still not the optimal solution. BIG-IP LTM’s wizard driven configuration menu, known as ‘iApp’, is designed to request the most basic system information from the Exchange administrator (Server IP addresses, hostnames, etc) and dynamically build the configuration on their behalf. The result is an optimal configuration that was simple and fast build, and much less prone to human error.

Hardware

Yes, the diagram above shows consolidating 5 TMG servers down to a single failover pair of BIG-IPs; and Yes, this is what we have often seen customers be able to do. To be honest, we’ve even seen customers go from much larger numbers of TMG servers to a single pair of BIG-IPs. BIG-IP is a special purpose platform with custom hardware built to provide advanced network services. Dedicated layer 2/3 chipsets, SSL and compression hardware, and specialized multi-core processing FPGAs are some of the pieces that allow BIG-IP LTM to manage and process network traffic at speeds and complexities not seen in typical server hardware. 

The others….

There are numerous other reasons to use F5 to publish Exchange, including

1. Single URL access, which gives the ability for Exchange administrators to give a single URL to all users, regardless of which device they will be using, or what protocol they will be connecting with.

2. Advanced Hosted & Hybrid Exchange deployment integration, that includes support for advertising a single point of client access and silently directing those users to their appropriate mail system. For customers migrating to/from hosted Exchange or Office 365, or moving forward with a long term hybrid solution, this removes the need to maintain different access URLs for the different mail systems. All of this integrates well with ADFS.

3. Integration with 3rd party monitoring Solutions, including System Center Operations Manager, that in conjunction with BIG-IP provide fine grain detail about the Exchange system and user access.

4. Open APIs that allow for management & automation through tools such as PowerShell and System Center Orchestrator.

5. Multi-application support, which allows customers to leverage the same F5 investment across multiple application environments. The BIG-IPs providing publishing for Exchange can also provide the same benefits for SharePoint, Oracle, VMWare, etc…..

 

I hope this post gives you some insight as to the benefits of using F5 to publish Exchange services. In light of the recent announcement regarding the future of TMG it’s time to consider alternatives, and F5 fits in well as a solution to provide network security, acceleration, and availability. All of the features described above are available in a lab edition of our virtual platform, allowing for customers to test the solution by running the BIG-IP as a virtual machine. Reach out to your F5 sales rep or F5 partner for information on access. If you want more information on F5’s solution for Exchange, check out our solution page

Oct 1 12

Ensuring Secure, Reliable and Highly Available E-mail Using Microsoft Exchange Server 2013

by rkorock

 

Application Layer Traffic Management (aka Layer 7) has been a critical component of an optimized Exchange 2010 architecture for addressing some very specific challenges around application awareness, load balancing and connection persistence. By leveraging the application layer intelligence in the BIG-IP Local Traffic Manager, Exchange 2010 system administrators have been able take advantage of benefits such as faster end user response times, increased server performance, and enhanced perimeter security. In Exchange 2013, Microsoft has removed the persistence requirement, transforming the Client Access Server into a stateless proxy. This may lead some folks to believe that the role of the Application Delivery Controller to support a Microsoft Exchange deployment has been minimized, if not eliminated altogether. Even without the persistence requirement, the reality is that there is still significant benefit in the Layer 7 awareness that an ADC provides in an Exchange architecture, and the overall ADC value prop that includes Layer 7 in fact reaches far beyond just that, providing enterprise-class scale, performance, reliability and integration that can only be achieved via a flexible and intelligent ADC. Let’s take a look at a few of the key reasons that an Application Delivery Controller is still the right solution for the upcoming Exchange 2013.

 

 

Perimeter Security… Exchange services continue to be deployed and exposed to the edge of the network where they are susceptible to anonymous attack. This is a serious concern that cannot be ignored. It is critical to make sure that there is a security perimeter around the Exchange environment that includes provisions for corporate and personal compute and mobile devices. The bottom line is that no connection or user should ever be allowed to the Exchange system unless it has been authenticated and authorized.

 

Performance… As Exchange adds integration into real time communication systems such as Lync, low level network issues (jitter, latency) start to have a real effect. Having an ADC that provides a full suite of network optimizations, from TCP to HTTP, will have a positive and noticeable impact on end user experience.

 

Application Delivery Platform… The integration between Exchange, Lync, and SharePoint in Office 2013 is tighter than ever, and most customers are going to want to leverage the same device for providing application delivery for all 3 (and possibly more!). There are simply functions, such as using the load balancer as your Lync Reverse Proxy, that you can’t do with a simple layer 4 device. Make sure you consider all the applications that will leverage this appliance before you make the decision to go with a basic networking solution designed to provide a single primary function, like load balancing and SSL offload.

 

Application Awareness… Nothing is more frustrating than connecting to an Exchange Server that is down, slow, or misbehaving. You should always be able to count on being sent to an Exchange Server that is available and performing well. Having an ADC that is capable of checking the availability and health of an Exchange Server, before the client attempts to connect, and using that information in its load distribution algorithms, translates into users always being sent to the optimal server.

 

Multi-site Awareness…. Exchange now supports (and promotes!) leveraging multiple active datacenters for scaling and redundancy. This is a feature that more and more customers are taking advantage of, and which a layer 4 local load balancing device simply can’t manage. An ADC that integrates with a Global Server Load Balancer (GSLB) will make sure e-mail and users are sent to the best datacenter for their respective services. 

 

Enterprise Class Hardware… Sorry partner, but PCs were not built to be network devices (I love it when I see a load balancer with a sound card!). Redundant power supplies, advanced clustering/failover options, lights out management, true Layer2-4 networking chipsets, dedicated SSL/compression hardware, capacity on demand are all requirements for meeting the enterprise Datacenter SLAs. It can’t be stressed enough that having the reliability and performance of enterprise class ADC hardware is critical in an Exchange environment

 

Monitoring & Reporting…. Having a load balancer divvy up traffic between a farm of servers using a ‘magical’ algorithm is one thing, but actually reporting on why those decisions were made, health of the servers, and end user performance is where the real value is. The load balancer needs to expose this type of information, and it needs to have well documented integration into the tools such as System Center that sys-admins use today. 

 

Scalability… We continue to talk to customers who maintain multiple mail deployments for a myriad of reasons, including acquisition. You shouldn’t be caught in the situation of not being able to consolidate mail systems because your network infrastructure can’t scale when you need it to. 

 

Conclusion

E-mail is widely considered one of the most critical applications in the enterprise today, and when the e-mail system performs poorly, or becomes unavailable all together, there is often a significant and measurable cost to business. Regardless if you need layer 7 persistence or not, today’s enterprise can’t leave the core messaging systems to chance with a cheap off-brand load balancing solution. A properly tuned Application Delivery Controller can provide significant safeguards that ensure the highest levels of availability, performance, and performance. The reasons for investing in Enterprise class advanced ADC go far beyond layer 7 persistence.

Sep 18 10

F5’s BIG-IP Access Policy Manager (APM) and SharePoint

by rkorock

F5 introduced Access Policy Manager for the BIG-IP Local Traffic Manager nearly a year ago. And as F5 often does with modules, they continue to add functionality with every release. This post takes a look at what is possible with APM in v10.2 and Microsoft SharePoint 2010.

What is APM?

In short, it adds secure access & authentication functionality to the core features already found on the BIG-IP.

Huh?

APM allows you to authenticate users at the BIG-IP, before passing them onto the resource(s) they are requesting. Beyond authentication, APM also provides a number of authorization & accounting (AAA) based tools, such as access policies, ACLs, SSO, endpoint checking, and more. Paired with a powerful Visual Policy Editor, iRules, and Active Directory/LDAP support, you have a very flexible AAA engine that makes securing access to your applications and networks much easier than before.

Does APM only provide secure access to web apps?

This is a common misperception that I wanted to clear up. APM supports all types of applications, web based or not, as well as general network access.

So what can I do with APM and SharePoint?

At its most basic, APM provides perimeter security by authenticating users before they are forwarded onto the SharePoint front ends. In effect, it ensures that only authenticated connections ever reach the SharePoint servers. For customers looking for more granular access control, APM can enforce a range of client side checks, such as antivirus/firewall/process checks, enforce ACLs, and use AD attributes to determine the level of access each user should have.

I plan on following this post up with some example configurations of APM and SharePoint 2010. Stay tuned!

May 3 10

F5 BIG-IP PowerShell Project – 2. Installation

by rkorock

 

Sorry for the long hiatus! I’m back, and because of the number of requests am continuing the posts on the BIG-IP PowerShell Project.

In this post, I am going to be installing the commandlets on my Windows 7 machine. The installation is pretty simple, and I’ve broken it down into 5 steps.

  1. Download and Run the Installer
  2. Start and Configure the PowerShell Environment
  3. Register the Snap-in
  4. Load the Snap-in into the PowerShell Runtime
  5. Verify the Installation

I am assuming that you have PowerShell v2 already installed on your system. These instructions will cover Windows 7 and Windows 2008, 32 and 64 bit versions.

The following instructions will guide you through installing the commandlets onto a Windows machine. You will then be able to run the commandlets on the Windows machine to configure and monitor your BIG-IP LTM.

 

1. Download and Run the Installer

 

The BIG-IP commandlets are packaged together with an .msi installer. You can download the package (iControlSnapInSetup.msi) here. Download this file to your desktop or wherever you can easily find it. Once this file is downloaded to the Windows machine that you want to install the commandlets onto, double click the file to start the installation process.

You can actually accept all of the defaults of this installer. I pasted the screens below so you can see the process.

image

In the screen above, click ‘Next

image

In the screen above, click ‘Next

image

In the screen above, click ‘Next

You may get the ‘User Access Control’ popup here. Go ahead and accept, and the installer will start installing. If all goes well, you should see the following.

image

Click on ‘Close’.

 

2. Start and Configure the PowerShell Environment

 

It’s time to register the iControl Snap-in into PowerShell, and that typically means that you’re going to have to change your PowerShell execution policy to “Remote Signed” (or “Unrestricted”, but that is less secure).

To set the policy, you will need to start PowerShell with administrative privileges.

Navigate to the Windows PowerShell icon in your start menu (Start –> All Programs –> Accessories –> Windows PowerShell –> Windows PowerShell), right click, and select ‘Run as administrator’.

Once the PowerShell windows appears, run the command below to set the execution policy to RemoteSigned

PS C:Windowssystem32> Set-ExecutionPolicy RemoteSigned

You will now get a prompt to verify that you want to change the policy. Select ‘Y’ for yes.

You can check what the current policy is at any time by issuing the following command

PS C:Windowssystem32> Get-ExecutionPolicy

The screenshot below shows the PowerShell interface when running the Set-ExecutionPolicy command

image

 

3. Register the Snap-in

 

Now you’ll need to run the setup script to register the Snap-in. You’ll need to cd into the directory that the files were installed into. Assuming you installed them into the default directory, here are the following steps you need to take.

I’ve split the following instructions up below for those on 32 bit and 64 bit Windows systems.

32 bit Windows

PS C:Windowssystem32> cd ‘C:Program FilesF5 NetworksiControlSnapIn’

Then run the setup script

PS C:Program FilesF5 NetworksiControlSnapIn> .setupSnapIn.ps1

64 bit Windows

PS C:Windowssystem32> cd ‘C:Program Files (x86)F5 NetworksiControlSnapIn’

Then run the setup script

PS C:Program Files (x86)F5 NetworksiControlSnapIn> .setupSnapIn.ps1

 

4. Load the Snap-in into the PowerShell runtime

 

So now you need to load the Snap-in into the PowerShell runtime so we can make use of the calls. Because the assembly was originally written for a 32 bit system, trying to add the Snap-in will fail on a 64 bit system. On a 64bit system, you need to run a small script (linked to below in the 64 bit section) to set the directories correctly.

 

32 bit Windows
PS C:Program FilesF5 NetworksiControlSnapIn> Add-PSSnapin iControlSnapIn
64 bit Windows
As I mentioned above, the current installer is a little whacked, so you have to run a script or the Snap-in wont load properly. These commands will open notepad so you can paste the script in, and then save&close it so you can run it. 

PS C:Program Files (x86)F5 NetworksiControlSnapIn> notepad psinstall.ps1

The script you need is located here -> Copy and paste it into the notepad session you just opened. Save and Exit notepad.

Now run the script you just created by issuing the command below

PS C:Program Files (x86)F5 NetworksiControlSnapIn> .psinstall.ps1

Now you can run the normal addsnapin command

PS C:Program Files (x86)F5 NetworksiControlSnapIn> Add-PSSnapin iControlSnapIn

 

5. Verify the Installation

Now if the Snap-in registered correctly, you should be able to tell by issuing a Get-PSSnapin

PS C:Program Files (x86)F5 NetworksiControlSnapIn> Get-PSSnapin

image

As in the screen above, look for the following

Name : iControlSnapIn
PSVersion : 2.0
Description : iControl Snap-in for F5 Device Management

If you found that, you’re good to go!!

Sep 11 09

F5 BIG-IP PowerShell Project – 1. Resources

by rkorock

Just to get you started, I wanted to list out some basic resources for using PowerShell to configure and manage your F5 BIG-IP Local Traffic Manager.

 

1. Microsoft PowerShell with iControl Homepage

This is F5’s main project page for their PowerShell integration. It is hosted on their DevCentral community site, so you will need to register for a free account to use.

 

2. F5 DevCentral Labs Forum, General Discussion

This is the F5 forum associated with F5’s “lab projects”, which include their PowerShell tools. You can post any and all your PowerShell/F5 questions here

 

3. PowerShell & F5 – Getting Started Video with Joe Pruitt

**Must Watch** video from Joe. Goes through the steps of downloading, installing, and using the PowerShell Snap-in. This video is a great way to get started. Highly recommended.

 

4. F5 DevCentral PowerShell Wiki Page

Great Wiki page on using more advanced pieces of the PowerShell & F5 integration.

 

That’s all for now folks!

Sep 6 09

F5 BIG-IP PowerShell Project

by rkorock

The ‘F5 BIG-IP PowerShell Project’ is a little challenge of mine to go through the day to day configuration administration of the BIG-IP using only PowerShell. No command line, no web interface. The purpose of me blogging about it is twofold -

1.Keep a set of technical notes that I can use again as reference. I tend to document a lot of the work I do, only because I cant remember s***, and this way I can share the information with you as well. I hope that it will help your efforts in learning how to use PowerShell to manage BIG-IP too.

2. Document the success, the failures, the satisfaction, and the frustration of using PowerShell to manage the BIG-IP from a perspective of someone who knows the BIG-IP, but is not a developer.

I plan on posting about once a week with updates. Please let me know if you find this valuable!

Sep 4 09

F5 clobbers Cisco in application delivery controller market share

by rkorock

Shameless, I know. However its pretty impressive that a company like F5 can compete (and win) against a behemoth like Cisco. I’ve been working for F5 for over 9 years, and since the day I started it was the same – Cisco is the giant, but we’re still able to maintain market leadership by have a better technology. Sometimes little guys can win.

F5 has 38% of the ADC market vs. Cisco’s 26%.

By Brad Reese on Thu, 09/03/09 – 4:53pm.

 

http://www.networkworld.com/community/node/44972?source=NWWNLE_nlt_cisco_2009-09-04

Aug 30 09

Minimize Windows Live Messenger to the Traybar in Windows7

by rkorock

OK, I’m still getting used to the new taskbar in Windows 7. One of the things that has been bugging me is that Live Messenger no longer minimizes to the traybar. By default in Win7 is stays in the taskbar.

Fortunately, you can force it to minimize to the traybar again! Follow these steps.

1.) Exit it out of Windows Live Messenger

2.) Navigate to WLM’s shortcut in the Start Menu. Right click on it, and select ‘Properties’

3.) Select the ‘Compatibility’ tab, and select to run it in ‘Windows Vista (Service Pack 2)’ compatibility mode.

4.) Restart WLM, and you should now be able to send it to the traybar. YAY!!!!