1. App Virtualization does not solve application delivery problems.
The promise: It’s a buzzword that we have all used for years. “Package” and “virtualize” your applications once and all your application delivery problems go away.
The reality: The skillset and money it takes to get the applications packaged in many ways far outweigh the benefits.
Part of the issue dates back to the introduction of “Windows.” In those days, applications were “designed” to work and interact together in one big happy circle. When you are virtualizing applications and allow them to “live alone,” many times you break the core functionality of the application. Microsoft Office itself, until only recently, was not recommended for application virtualization.
I view application virtualization like a trip to the beach: You’re all excited when you start driving but hours later you are just ready to be there. Once you start down the road you quickly conclude many applications will still have to be locally-installed and will be extremely challenging to package. Be prepared to spend hours in ProcMon.
The trip will get even more fun when you reach a traffic jam: when reports of application hangs, freezes, crashes, and lost functionality are reported by users. You have an extremely difficult task of determining whether the issue is vendor or package related.
The solution: The real solution to the application delivery problem, unfortunately, is to change the development model itself. Compare this to Apple, Android, and the Windows Store applications, all of which were built around a platform where applications could live and run in a “bubble” and be truly virtualized and portable.
I will admit it is impressive that you can store and run applications over the network with the latest App-V 5 and SMB 3 and does open up additional use cases for this delivery method. This is especially helpful in VDI where you can have a single installation and storage repository of applications via a simple Windows file share.
My latest tool in handling this elephant has been FSLogix which allows me to “hide” and “assign” applications based on user. I mention tool because application delivery for me is:
Local installation + Application Delivery + FSLogix
While many modern applications can easily be distributed via an application virtualization model, there are many that will must be deployed and physically installed.
Think before you virtualize!
2. Bugs are not features and should be fixed.
You find a “bug” in a product only to report the issue to support and be told that it’s not a true bug but a “feature” of the product. This comes only after many long hours on the phone convincing support that you actually do have an issue because generally they have no idea how the actual product should be used
It’s mind boggling to me that we, the technologists, have become the Quality and Assurance department for many of these companies. I’m sorry… I didn’t get this memo nor is my organization aware of how much time I actually spend managing these types of issues on core business projects.
In my opinion we do it to ourselves when we continue to support companies that function on this type of business model. I think we should start tracking resource time allocated for these issues and make vendors discount future purchases.
And the biggest pink elephant in this room goes to Citrix. I mean how many years have their consoles crashed over and over, time after time?
I have always been impressed with Microsoft for their ability to acknowledge and resolve bugs in their operating system platforms. Now if we could only get the Office team to be as responsive.
3. “Profiles and Policies” are antiquated
This is one that has irritated me for years. I’m floored that it’s 2014 and user profiles and policies are basically untouched from Windows NT 3.x!
Many of you know that Kevin Goodman and I drafted the first specifications for “streaming user profiles” years ago only after I was sick and tired of Microsoft making no progress on the issue. Even then, I envisioned a day where streaming would become antiquated itself: user profile data should live centrally not on the target box.
Even in 2014, user profiles remain a top challenge in the desktop/VDI space. When you look at the upcoming BriForum, you will find topics like:
- Profile Madness: Roaming, Microsoft UE-V, AppSense & UPM. What Should I Do?!
- How Folder Redirection Impacts User Experience and Breaks Applications
I always knew Microsoft, storage, and other vendors would have to come together to solve this problem. As we move toward SMB 3, highly available file services, and native VHD/VHDX file formats this is finally becoming a reality.
Policies still remain my biggest “irk”. Come on Microsoft: Group policy architecture and processing speed should run like a modern PC but instead they run like a Commodore 64. I will give it to Microsoft: the result set of policies and reporting is impressive but under the hood it’s a mess and continues to contribute to login delays.
The file format(s) for the policies are technically flawed. INI files are bad: each value to be retrieved opens up the entire INI file, parses the value, and closes the file. And this occurs for each and every value in the file. The “version” INI file contains many values. The “.POL” file (which the actual policy data is stored), unfortunately, is not any better. If you look at a “reg” file, you will find a key with multiple values. In a “POL” file, every “registry value” is stored with along with the entire registry key. This not only increases the size of the file but processing time of policy. If you Procmon, you will quickly conclude that each and every policy value “opens” and “closes” a registry key for every value set. Ridiculous! This only increases CPU and processing time. The registry key should be opened and all necessary values set before closing. And I love the XML file format for Preferences… not! While the ability to “manage” preferences via XML files is nice, preferences should be “compiled” and optimized before use.
Policies need more “target” attributes and abilities similar to preferences without having to learn complicated WMI filtering.
This brings us to login time. While I admire Microsoft for improving the concurrent login scalability of the OS, recent Windows versions have decreased login time since Windows 2003 not improved it.
4. VDI isn’t the solution for everything.
Everybody wants to virtualize their desktops for ease of use and centralization of management, but it isn’t the only solution. The end-user experience will never be as good as the physical client. In many cases it only makes sense in certain environments, like healthcare and manufacturing, where desktops need to roam with the user. Otherwise, many times desktops still remain cheaper and offer better performance.
Then you have the problem with desktop persistence. Many vendors promise solutions like a “personal disk” or true persistent VDI desktops but in the end fall into the category of #1. The reality: until the user profiles and application development platform changes, persistent desktops will continue to be struggle. Many promise to deliver “layering” and be future-proof for things like Windows service packs and updates. As a seasoned C++ developer myself, I know too well not to get caught up on the hype.
Keep in mind VDI is only a “presentation layer” solution for the end user. As application delivery platforms mature, similar to an app store experience, and as mobile devices get more powerful, processing will one day return to the end point.
5. Stop changing the names on everything
This one makes perfect sense to me: Let’s build a loyal following around a product and change the name every year. I mean everyone does it right? Oh wait, the software industry is one of the only ones to exploit this marketing model. And we all know why: to confuse people into thinking they are getting a “new and improved” version and an entirely new product.
If you’re like me, you’ve hired a full time translator for the Citrix products with all the renames.
I’m not opposed to name changes, but only when they make sense.
6. Project managers, developers and support lives in a bubble with no communication.
How many times have to gotten a new version only to hear a “core” feature is missing? Or call support only to feel like you are talking to your Aunt who just got a new computer? My favorite is when they act like the issue cannot be reproduced when you know it can.
They have no idea how the product internally works, which, means troubleshooting the actual issue is even more difficult. You quickly find yourself living in “ProcMon” and “Wireshark” as you try to help your technician understand the issue at hand. For my fellow developers, sometimes it’s easier just to reverse engineer the product with something like Reflector for .Net applications or IDA Pro for C++. Another favorite is API Monitor by rohitab.com (free). You will hear an “eerie moment of silence” when you quickly prove the issue and turn the tables around back on the vendor.
“Troubleshooting/root cause analysis time are inversely proportional to your understanding of the internals of a solution. Root causes analysis time (t) will grow exponentially as knowledge of the solution decreases.” – Michael Thomason
Let me give you a history lesson here: Back with the original release of SMS 1.0 (SCCM for those newbies), Microsoft designed the product around what they needed to manage their internal boxes but sought little or no customer feedback nor were they aware of how customers actually deployed software or their domain/network infrastructure. The result: SMS 1.0 and mostly 2.0 was a complete flop with many service packs required to get the product stable. For Microsoft, this was a lesson learned. Fast forward to today, Microsoft continues to promote and maintain a healthy relationship with their customers. From their product managers, to PSS support, to their “Developers On Premises” program (which brings developers in your office to see actual real-world problems), they have made great strides in this area.
A business is first and foremost a service and how companies continue to get away from this model is beyond me. The quality of your product and your support team is the “face of your business”. I feel like with many of the vendors I’m picking up my date wearing only jogging pants and sweats instead of being properly dressed for dinner.
Product Managers need to continue to push executives to invest in the technology of their products as well as better interface with customers on the actual requirements of the products they are designing.
Developers need to take more pride in their code and have better communication with support. And support needs to be properly trained on how to quickly diagnose and triage issues.
Software company executives needs to stay more “plugged” in: both with their customers and with their corporate culture.
Software companies only sell two things: intangible products and services. My prediction is that as more services go cloud and the software industry evolves, it will become easier for customers to move from platform to platform. Without solid, loyal customers, they may find themselves quickly standing alone without any friends.
It’s funny how only when Microsoft wanted to do Azure, did they realize their products lacked enterprise features to make a true cloud platform possible. Did we really have to stay on SMB 1.0 for over 16 years without any improvement?
Bob Farrell, who opened up a chain of 120 ice cream shops in the mid 70’s attributed his success to “giving his customers the pickle”. Translated: Do what is it takes to make things right! It’s how I have built my career and I’ve used Bob’s training at many organizations which I have done consulting for.
Vendors: Give us the pickle!
You can read more about Bob’s training at www.giveemthepickle.com.
7. Not always the vendors fault
We’ve all been setting around and heard the dreaded words… “It’s Microsoft… It’s Citrix… It’s Acme Software...” Many times the actual issue has nothing to do with the vendor as much as the implementation of the technology or with the application itself.
The result is two-fold:
- Lack of understanding how the technology solution works.
- Little or no monitoring/troubleshooting tools used by the organization
- You have a GPO processing issue: where are the policies stored in the AD database? Where are client extensions registered?
- What is the MUP?
- For a given DNS query (which we do every day), how does Windows handle queries when multiple adapters are used? What are standard DNS response codes? What core DLL handles DNS resolution?
- What is msscore.dll?
The point of the quiz is not to put down anyone for lack of technical knowledge; you can make your own quiz for your respective technologies. The point is make you ask yourself: do you really know the solution works? Every day it becomes harder for a single person to be a central knowledge keeper for an organization. Team cohesiveness and communication will become even more important in the future as solutions become more complex.
I love to use the term “Think Horizontal”. This simply means learn technology, how it works, and how it can interact with components to form a solution. For example, take a horizontal solution like VDI. Verticals layers of the stack might include the operating system, applications, network, storage, hardware, etc. In the future vertical “knowledge workers” will be required to support highly complex horizontal solutions. Only then can you triage issues and determine root cause efficiently.
8. All IOPS are not the same
There are IOPS which we do to store information (i.e. database, Word document) and IOPS we do because we have to only for a moment in time (i.e. page file entry, temporary file, etc.).
With all the advancements in storage recently, the market is hungry for a solution which meets the use case for the “temporary IOPS.” For this you want them as close to the actual device as possible and as fast as possible. No redundancy… just fast, cheap, and simple.
9. Printing is broken and needs to be fixed
Printing is one of the most complicated and unreliable parts of Windows. The real issue is, only until recently, we were running on the same driver format as Windows 2000. I’ll admit: making something “digital” into “paper” is a complicated task in itself.
While there are many excellent and improved features in Server 2012, there remain many “holes” and limited third-party solutions.
Since I can publish printers to Active Directory, if I move a printer from one print server to another, why can’t Active Directory be used to change the location on the client itself? Where is client driver fallback? The reporting and management of print jobs still remains limited.
There is no standardization among the vendors on basic printer functionality. Take a simple concept like “stapling” and “duplexing”. Every vendor is responsible for writing their own driver and how to implement it. And print vendors: improve your drivers!
Item #6 should address many of the issues here.
10. Show me a dang demo!
You’re looking for a product and visit the vendors page only to see a bunch of bluff about the product and how it perfectly solves your solution. There is no mention of the latest version of the product. You click on a “video” only to find another 15 minutes of more bluff. No screenshots… nothing!
One of my favorite lines: “Get in, get out… go home!” Why so few vendors show the actual product in use is beyond me. If you can’t visualize the product you may not quickly understand how it will benefit your organization.
And put your pricing online! I do not want to have to call for a quotation.