So, normally i reserve posting quick tips on technical details here.  But, i spent hours troubleshooting an issue and wanted to post it SOMEWHERE so the search engines pick this up.  And it's less than well documented.  I'm hoping by posting here someone doesn't spend the time I did trying to fix this.

If you use HP ProCurve Manager to manage your ProCurve switches, you know its a pretty powerful product.

There's a security feature that you need to modify if you want to have another workstation view the information from your ProCurve Manager server.  By default, no other workstations can connect to your PCM server, such as an Operator or extra monitor in your NOC.  If you install PCM on a workstation, and try to connect to the PCM server, you will receive a message:  ":  the server would not authenticate this client, you may need to upate the list of authenticated clients on the management server"

A search online and in the help yields nothing.  So, here's what to do...

On the server, locate the file ACCESS.TXT.  Edit this file.  It will probably be empty.

add a line of the address of the workstation that wants to connect, or even easier, add the subnet of workstations that you trust to connect (like 10.*.*.*)

restart PCM client on the workstation, and you should now be able to connect...  hope that helps.

I'm continuing to get lots of interest in application virtualization and in particular VDI - hosting the entire desktop and a user simply "remotes" to their desktop in the cloud / datacenter.  Spent some time with Citrix, who is a close partner of Microsoft and the MTCs. 

 We deployed an interesting solution that makes me want to revisit the whole "stream the OS to the desktop" scenario.  With Citrix added on to Windows Server 2008, you can boot from an ISO image.  We use that here to avoid some conflicts with an existing demo, where we boot the ISO and start up a VHD, and then connect the user to the VHD for their VDI experience. 

But this got me thinking... if i can boot to an ISO, i'm in effect streaming the OS down to the workstation.  if i create my own special ISO image, and can send it down as the workstation boots, we can basically operate a diskless workstation.

So, now that the environment is up & running here, i need to spend some time with this to see how this could enable some solutions in highly unmanaged environments (retail scenarios, fast food chain restaurants, etc.).  Stay tuned.

Here's a total ad-hoc video posted on edge about our new MTC in Chicago.

(also known as "how i spent my christmas vacation")

 http://edge.technet.com/Media/Inside-the-new-Chicago-Microsoft-Technology-Center-MTC/

I'll be speaking today at the Technical Experts Conference (TEC), which is Quest's technical conference where they have topics about Exchange and Active Directory.  I'll be presenting on the work we've done at the Microsoft Technology Center Chicago about making our new datacenter virtualized, and the value of using VLAN Tagging at the VM /switch level.

I'll try to get my deck posted somewhere.  If you're at the conference stop by and say hello...

Windows Server 2008 added two new features that enable some very cool remote-use scenarios, that really enable some new ways for using and publishing applications:  RemoteApp(tm) and Terminal Server Gateway.

RemoteApp allows you to publish out an application, as if it was installed locally on the users workstation but actually runs in the memory space of the server.  This is ideal for users that need access to an application every once in a while, or need it remotely, but doesnt require you to install anything on the users desktop.  And if the program uses a file extension, like .MPP for Microsoft Project files the client can actually recognize this and start the remote program on the clients behalf.

Now this is great if you are on the corporate network or VPN'd in.  What if you want this access for a person who only has https:// access?   Dovetail RemoteApp with Terminal Server Gateway, and you can enable this across untrusted networks. 

We ran this for a very large customer who wanted to proof-of-concept our Microsoft Dynamics applications, and it worked like a champ.  Now, we had to create a cert through Microsoft trust chain, which was the worst part about the process, but once setup it was hands off.  and *very* enabling!

I can really see this changing way applications are deployed and managed...

I’ve been spending majority of my free time rebuilding our core infrastructure services in our data center at the Microsoft Technology Center in Chicago.  We’re moving offices in December 2008, so perfect time to do this. 

I’ve been wanting to look into VLAN identification feature of Hyper-V, and see how this can really benefit us and our customers.  After some reading and experimentation got it figured out and wanted to share my experience...

In the old days, I’d have a physical NIC for each VLAN and configure the switch port the NIC went into to be “hardcoded”  (untagged in HP ProCurve lingo) to a VLAN.

On the Server, I have it configured according to the common preferred practices:  one NIC on Management network used only for management, the others are are cabled to a port on our ProCurve switch .   Important note:  the physical NICs themselves are not VLAN tagged (i.e. properties of the NIC card), but the port on the switch that the NIC goes into is marked as TAGGED.

Wall Street Journal had an article today about application virtualization at the desktop.  I never thought I’d see the day when this topic would end up in the ‘Journal.  Wow. 

The thing that makes me cringe is thinking about the conversations we've had with customers on thsi topic at the Microsoft Technology Center Chicago.  We're having flashbacks to infrastructure discussions held back in 2003, and in this case hoping history doesn’t repeat itself.

Think back to the early 2000s:  server consolidation was the buzzword, and every IT department soon had this initiative in their portfolio of projects to complete to “reduce costs”.  All my customers wanted to throw hoards of physical servers onto one big server to increase their optimization, usually through virtualization.  What we quickly learned from customers was there were several approaches to server consolidation, not just virtualization, and taking a step back and choosing the most appropriate approach to consolidation became the most important factor in predicting success.   For example, its very possible and achievable to consolidate File and Print services, or Exchange email services or SQL databases, onto fewer number of like boxes without having to virtualize. 

We saw some glorious failures out during that euphoric consolidation wave, and we can take the same learning’s and apply them to the newest buzzword:  application virtualization (we’ve also heard it referred to as “OS streaming” and “on demand installs”).  When we saw the first wave of server consolidation hit, IT shops wanted to stack tons of servers onto few number of physical boxes.  What we learned was:

-          There are many approaches to consolidation, and some thought needs to go into which is the most appropriate

-          Good IT practices (change management, monitoring, etc.) trump any technology solution

Introduction to Application Virtualization and “Streaming”

If you aren’t familiar with application virtualization, it’s taking an applications running instance (installation, execution, etc.) and encapsulating it, so it can run in its own isolated environment on a workstation.  Microsoft’s solution in this area is called Microsoft Application Virtualization (MAV), previously known as SoftGrid.  This solution is part of Microsoft’s Virtualization portfolio which includes server virtualization, presentation virtualization, and desktop virtualization.

Application streaming to desktop is somewhat new and has lots of attention (see Gartner’s Hype Cycle for PC Technologies, June 25,2007).  Microsoft purchased SoftGrid about a year ago to have a solution this space, and it’s a pretty compelling solution as are others out there with a lot of viable implementations.

As we move to application streaming, we start shifting the “work” to other components.  It inherently increases the reliance on other core components, most importantly the network and general connectivity.  For example, another virtualization technology solution in the space takes an entire application and compiles it into one .EXE by taking a snapshot before and after an application installation.  Therefore, it’s highly isolated from other apps that run.  But, this requires the network to be always available, must be capable of a large increased load of transferring the entire .EXE across the network in one big bite.  MAV, on the other hand, transfers only what is needed and not the entire application, but still has a (reduced) reliance on the network.   

Suitability for all situations

This has some real potential for organizations where there are large number applications, often due to factors like acquisition or consolidation in an industry (such as healthcare).  Another is where multiple distributed IT departments have come under one umbrella as a part of IT consolidation, removing departmental or divisional IT groups and collapsing into one. So, now where each division may have had its own order system or HR system for example, now may need to run several side by side.  With every app isolated, this becomes a very compelling option due to the large number of application install combinations per workstation.  The result of all these apps that need to run side by side would be a large and impractical testing matrix.  Value form app virtualization would come from the reduction of time needed to test out the different iterations of application compatibility.

Where we have the most concern are the IT departments which are engulfed in the hype to the point where this is the solution (similar to server consolidation), without considering other factors such as their ability to support this environment. 

Impacts of streaming

Streaming removes some big headaches.  But, it has some caveats: 

The IT groups must have a highly reliable set of operational practices, and robust experiences in network and application performance monitoring.  Your dependant components (parent or host OS, router, application, workstation, etc.) has to expose out performance information.  Also, your management tools must be there to capture and smartly digest that performance information into actionable tasks.  This is probably the single, biggest overlooked area in all of virtualization (such as server virtualization, where there’s a strong need to monitor the host in addition to the child VMs themselves).

Bottom line: 

1) If you aren’t using good IT operational practices today, such as MOF or ITIL, you better start and get good before taking on immature technologies such as OS streaming.  Good IT practices trump the best technology solutions.

2) If you aren’t that mature in IT operational processes (see IT Infrastructure optimization), you might be better consider more mature solutions like traditional application packaging and distribution.  This is a very proven and established solution with a lot less risk.

3) If your organization is not traditionally an early adopter to leading edge solutions, your audience   probably won’t have the appetite for such a bleeding edge technology.   We’d encourage copious amounts of testing and validation for performance, network latency, etc.

At the Microsoft Technology Center Chicago, one infrastructure topic that never seems to be absent from our customer agendas, no matter their level of IT maturity, is the concept of a “locked down” desktop.

The locked down desktop, like its brothers server consolidation and single sign-on, is an umbrella term that often means different things to different people. The drive here by IT, I find, comes down to a desire for better desktop management, and more often grows into philosophy of what exactly are IT departments trying to accomplish by locking-down.

First off, I tend to avoid using the term locked down. It gives off a negative connotation, and I have yet to find a user that wants to sign up to be “locked down”. I prefer, and encourage our clients to use, the friendlier term “Enterprise Enabled Desktop”. (side note: our legal team and desktop marketing had no interest in protecting this term, so please feel free to use generously in your own IT marketing.)

After a brief discovery and understanding of what a client is hoping to accomplish in an Enterprise Enabled Desktop (or EED), the answers most commonly break down to:

• desire for reduced configurations, therefore reducing known variables for updates
• removing access to configuration areas on the workstation that IT doesn’t want users changing, reducing the overall costs of managing the desktop (i.e. reduced help desk calls or support hours)
• more control over the configuration of the end user desktop 

It’s no secret Microsoft has a wealth of tools to help IT departments gain and keep control over environments. Many are shared here later, but before diving into a solution I find it most helpful to prime the EED conversation with an illustration of my “Spectrum of Workstation Management”. I usually draw a line on the whiteboard and explain that on the left side is what I consider the wild, wild west, and the right side is your fixed function corporate device.

Here’s an analogy I often share: Imagine a driver for a package delivery company. This driver is given a truck every morning in which he or she makes deliveries. Can they take that truck home on the weekend to help move his friend’s apartment? No, that increases liability for the company, and increases the wear and tear among other things. Can they take that truck in for a paintjob or to install a new radio? Or course not, it’s not his truck. That truck is a corporate asset, given to him for the purpose of conducting his job duties. This same perspective can be used for a corporate workstation. I put this at the far right of my spectrum.

On the far left, as I mentioned, is the wild, wild west. Anything goes here. Users can install, change, and tweak anything they want to. They can update the drivers, install a screensaver the pulled down from any website, copy their personal movie collection to the device. Basically, treat it they would their home machine.

There is tons of evidence that a machine closer to the left side of the spectrum costs more to own and maintain (Gartner says: $5,500/yr). But, traditionally as a workstation moves further to the right, the amount of freedom the user has on that device decreases. This can be good or bad, depending on the tasks the user needs or wants to perform.

The point I make with our customers is this: classify your users by find the most appropriate place for your classes of users and/or workstations, and where they should be on the spectrum. It is probably not appropriate for all users in an organization to be in the same spot on the spectrum. For example, non-techie groups that perform a fixed set of tasks such as HR or customer services reps might be pretty far right on the spectrum. Developers or executives might be more in the middle or closer to the left, giving them more freedom over their machines yet still having some basic policies applied to their machine to ensure some level of corporate compliance or adherence to corporate IT policies.

(another side note: This is often where the “thin clients” which act as a terminal and connect to a terminal service in, but too much to cover here)

Once the classes of users are identified, then we begin a very basic discussion on options available for helping enforce the level of placement. There are many tools that help support the locations of workstation on that spectrum. At the very basic is Active Directory and Group Policy, which manage the most basic of settings and configurations for user identity, machine identity, and basic configuration. Once a machine is joined to the directory, we can introduce server and domain isolation to know that authorized clients can connect, and establish the corporate identity. You can also consider Network Access Protection in Windows Server 2008 here.

More advanced management tools as we move just a bit further to the right is Microsoft Software Update Services for critical patches. Vista has added many features and modification of existing XP components specifically for making it more granular and enabling for users to have more control without the need to be an administrator on the workstation, such as adding a printer. User Access Control, while being considered a nuisance by many, when managed through policy helps to get more classes of users closer to the right and more fixed-function that ever before.

As we get closer to the rightmost side of the spectrum, System Center Configuration Manager (SCCM, previously known as Systems Management Server, or SMS) comes into play, which enables a complete solution for workstation management – from bare metal provisioning to full management and even drift from a desired state. We could also get into more advanced areas such as client monitoring with SCOM to really understand performance and trending of a workstation for future diagnostics, troubleshooting, and response levels.

Keep in mind - even though developers and users with laptops might be father to the left, they can still have some basic, core policies applied (Active Directory group policies for things like firewall, proxy, and NAP) in order to maintain some degree of manageability and confidence of the security around that workstation without impairing the ability for them to do their job function successfully.

Information on all the technologies discussed here can be found on Microsoft.com. Search on these terms:

• domain and server isolation
• group policy
• Vista improvements for manageability
• SCCM and workstation management

Healthcare applications are notorious for using proprietary identity systems for user authentication and authorization.  It’s a problem in many industries but seems to be most rampant the healthcare industry and continually challenges most every healthcare customer that comes into the Microsoft Technology Center (MTC) in Chicago.

It is surprising, but not expected.  As healthcare application developers seek to get their product to market quickly, and the fact that the application is typically sold to the “almost” end user customers at healthcare providers, little consideration is given to see if the application has the ability to honor any kind of enterprise directory IT may have, or even leverage a common identity provider like LDAP or Kerberos.

I have yet to speak to a client in the healthcare field that comes to the MTC to consolidate down their identity management where this doesn’t come up.  And it always comes up as a hindrance as they try to reduce infrastructure complexity and get to reduced sign on, let alone single sign on.

This prevents optimization of healthcare IT environments.  Our healthcare clients are unable to increase their IT maturity without driving down the complexity around identity.

The biggest reason application providers don’t do this correctly, I’ve found, comes down to education. Let’s look at a much better way for the app developer to have this necessary functionality and be a better IT participant.

The most beneficial way for application authors to compose their application is to embrace a mechanism that can allow for a local authentication source, yet be able to honor an upstream enterprise directory.  While this sounds complex, it is actually easier to follow some preferred practices that can actually reduce the effort and time for an application developer to offload this component of plumbing for any and all applications.

Microsoft offers several methods for an application developer – Active Directory Lightweight Directory Service, or AD LDS (previously known as Active Directory Application Mode, or ADAM) is ideal for a standalone application that requires a store for managing users and identity.  This is ideal for standalone applications – can store applications settings in addition to the basic LDAP signon.  But what if this application needs to authenticate to an enterprise directory based on Active Directory?  No problem – the AD LDS can honor an upstream Active Directory (AD) implementation.  What’s even better is the local application settings can reside in AD LDS while the authentication still happens at the AD level. No extra replication.  Keep in mind that AD LDS and AD use the same interface calls and parameters, so its relatively easy for app developers to leverage AD skills for AD LDS.

Customers of these applications, in an attempt to streamline and optimize are starting to use this criteria in selection of healthcare applications.  We are advising all customers that come through the MTC to challenge their application vendors to honor their enterprise directory source.

Lots of information on how to use AD LDS on microsoft.com, here’s a link to the FAQ: http://www.microsoft.com/windowsserver2003/adam/ADAMfaq.mspx