Troy Wilch

AppV 4.6 (beta) is here!

twilch — Tue, 04 Aug 2009 04:15:26 GMT

At last, the long awaited version to be able to run on 64bit OS’s. After finding out this afternoon from about 20 RSS App-V feeds regarding that the Beta release for testing, I couldn’t wait to get home and get it tested on one of my 64bit systems. Sure enough and without any issues at all, streaming is in full effect from my streaming management server to my x64 Vista system.

The best part, now I can regain the 1Gb of lost RAM my system has undertaken because I choose running 32bit in order to run the ~80 virtual apps. Now I’m off to prime my Win7 image in ConfigMgr R2 SP2(beta) and see if my laptop gets upgraded overnight to Win7x64 with USMT4 and the new AppV client install task.

A long hiatus..time to start back up!

twilch — Thu, 04 Jun 2009 04:05:24 GMT

It’s been a while since posting anything on here, but needless to say, I’m back to continue some more insight into App-V.

During the time away, I’ve gone through some job changes leaving the consulting life back to the public sector as well as changes in my military requirements. Also during this time, I elected to take on creating a series of training videos around App-V which I hoped to have available for paid subscription on another site. Unfortunately the time commitments involved to undertake this during a time of so much change during this crazy economy and transitions, that all came to an end.

So what do I do with the videos I did produce. I’d hate to waste the time I spent away from the family to work on these things only to keep them on my hard drive. So I plan to do some editing to them first and post them up on here. Might as well share the good info, so stay tuned to some follow-up blogs I plan to do on them..for free!

MDOP Charter membership

twilch — Fri, 26 Sep 2008 03:20:51 GMT

Wahoo, just got an email welcoming me to Microsoft's MDOP charter member program. The first 200 people worldwide to take and pass the exam gain membership and receive a MDOP charter jacket, a desktop crystal recognition award and insider knowledge, which to me is the real award I'm interested in.

Want in, it's not too late! During a MDOP concall with Microsoft's PoC program for partners, I asked if the 200 number had been reached. He didn't say exactly how many have passed it, but said almost at the half way mark. So get on prometric, find the 70-656 exam for MDOP, input the "MDOP" code for a free test, and get in there. The hardest part is scheduling the test to get you motivated..so let me help you out, Click here!

Time to get generous with ConfigMgr R2 client cache sizes

twilch — Wed, 03 Sep 2008 06:02:28 GMT

One of the nice things about being a consultant is gaining collective knowledge in how organizations run and operate their SMS/ConfigMgr environments. One of the things I run across from time and time again is, folks are stingy when it comes to client cache sizes.

The down side of setting the cache too small is if you have it set for say 1024 and you now want to deploy a large package(which is not always recommended to run from DP), it needs to bring the entire package down into cache before running. Now it will try and purge the cache to make room, but if it can't make it available or the package is too large, the package fails to install. This happens all too often I've seen.

Remedies:

Use the SMSCACHEFLAGS=PERCENTFREEDISKSPACE.
- You can use this along with SMSCACHESIZE=40 in your client install properties to set the cache to 40% of total free space at the time of installation. So if a machine has 10Gb free space, the cache will be set to 4096 of allowable space. This doesn't mean that after installation, the machine is left with 6Gb of space, only that it can grow to 4Gb of cache.
Use the Cache enlarger script.
- To set the percentages after the client is already installed, you can use the attached script to run against machines to have it determine the value of free space available and then set the cache to a preset percentage.
Set Cache Size with Right click tools
- You could get creative with collections and base the criteria for them off different space available on client machines. Then use the right click menu add-on to set the client cache with a preferred amount. while this may be easier, it's harder to establish what is a good size for a collective amount of machines without going crazy with a bunch of collections.

While SMS 2003 defaulted to only 250Mb of cache size, MS increased this to a default of 5120 unless specified differently. I believe this could be due to OS deployment being a popular feature in ConfigMgr and 250Mb is no size for deployments.

So where am I getting at here with all this Cache Size stuff?

Glad you asked. In Release 2 for ConfigMgr 2007, App-V will make a big hit as it is now being integrated into ConfigMgr. As you already know, SMS/ConfigMgr has had 2 different deployment types to it's clients:

Run from DP - This is generally good for smaller-medium size packages as the packages stay on the local distribution point and runs from there.
Download and Execute - transfer a copy of the package to the client cache and install locally from there. If your installing Office 2007, this could take up 1-2Gb alone. After installation, this content is not always removed. There is a cycle that should routinely purge old packages or purge when space is needed. This doesn't always happen though.

Now with App-V, though a little different in name, it is close in principle. With an App-V advertised package, you have 2 choices:

Stream from DP - This is where the SFT (main App-V file) is left on the DP and streamed down to the virtual client cache and launched. For this method, the only space being consumed on the client here is the APP-V cache. It's a whole other cache value set, but the ConfigMgr cache is not utilized.
Download and execute - It transfers the SFT file for the App-V package to the ConfigMgr cache, then when the application is launched, it also loads the virtual app into the App-V client cache.

The thing to understand and take away is, the space requirements for download and execute of virtual applications double as both caches contain copies of the packages. The SFT file is left pinned to the ConfigMgr cache for any repair needs of the virtual application. But at this time, the normal cleanup process won't remove the SFT files from the ConfigMgr cache. So either plan to use the streaming delivery method when possible or plan to allot the space requirements for Virtual applications.

SMS Cache Enlarger Script

App-V management pack for Operations Manager exposed

twilch — Wed, 30 Jul 2008 05:58:08 GMT

Since I've been working quite a bit with Operations Manager this last year and have tinkered with creating my own management pack for App-V (this of course before I heard that one would be released), I was pretty excited to get this imported into my OpsMgr at home and see how I faired with the setup of my VAS server in secure mode. Unfortunately, It came out too clean like the view you see below, so I decide to dump my installation and rebuild from scratch again to see how much red I can produce.

Well, I got what I wanted. After the re-install of the VAS and OpsMgr re-discovering it as an App-V server again, it looked bad, which is good. It showed the App-V server service not running, a configuration issue, the ACL's were not set for the new server cert I reissued.

Below you will see what makes up the health of an App-V server (lightweight or heavyweight) in this management pack. Hopefully more work is being done on this MP around adding canned reports since there are none, a distributed app would be nice so I don't have to make one, but more importantly, the performance monitoring specific to App-V.

Now to find out if the ConfigMgr 2007 management pack is planned to be revised to monitor the App-V integration on R2.

The Optimized Desktop - Separate, then bring it all together!

twilch — Tue, 24 Jun 2008 08:34:06 GMT

Either I have my blublocker sunglasses on or things are just getting clearer on where Microsoft is taking us in the Desktop space.

In the past (and still is in most places), IT admins struggle to manage multiple images, fatting them up with all possible drivers, every application that deemed critical which meant ~20-30 applications and running around with CD's or DVD's to load onto client machines when they break. Roaming profiles made sense so the users setting's would restore and then there was the hour/s of manual setup to do. What a time!

Around 3 years ago, I was demo'd by a company named Softricity (maybe you've heard of them!) that really began to change my thinking of managing corporate desktops. It brought a whole new perspective in the way hardware and software can be separated into layers to make it easier to manage. Then with BDD 2007, the idea of separating drivers from the image was detrimental to getting down to a single neutral image.

Recap - "So let's see here, we separate the hardware from the OS image by dumping the drivers, we separate the applications from the OS image thus reducing frequent image modifications, the image is more lightweight which is easier to deploy (just in time since Vista is heavy enough on it's own) and by incorporating things like folder redirection and offline files, even the user's data is nearly separated."

Today , we are now seeing things like ConfigMgr SP1/R2 come out that wraps all these capabilities together.

1. Hardware - Through SP1's WOL and out of band management capabilities, we can manage the hardware down to the very basic levels of the BIOS and NIC.

2. OS - With OSD, it now centralizes your drivers into catalogs/packages to get you down to nearly one neutral image to manage. With offline hotfix integration for Vista images or the hotfix task sequence, injection of the latest hotfixes can update the image automagically leaving little reason to have to re-cut a new build. And even then, a build and capture Task Sequence can automate that entire process for you. (Go get some coffee and wait for payday!)

3. Applications - In Release 2 (R2), ConfigMgr will be fully integrated with application Virtualization. With this capability, you can strip out nearly all your applications from you image, thinning it down as much as possible is the idea here, and role basing those applications to AD groups or user/computer collections. This way, no matter where you deploy that image to, when the user logs on, the applications that HE OR SHE needs will be available to them dynamically by streaming on demand or launching locally cached virtual apps, good for those Laptop users. So no more fatting up the image with all those apps that "might" be needed.

4. Data, User settings - Through both folder redirection and offline files, separating the user settings and data from the OS is still some work. ConfigMgr does have the ability to run the User State Migration Tool which does a great job in migrating the user from machine to machine. Especially since virtual application settings can be universally controlled by Group policy using a networked home directory for the %appdata% variable. May be a good idea to make that folder offline for your Laptop's in a separate GPO for offline configurations to synch up next time they connect to the LAN.

Future, things are beginning to shape on the horizon around more dynamic desktop computing.

With Microsoft's purchase of Kidaro to include Enterprise Desktop Virtualization in the MDOP early next year, a whole new set of incredible changes are on the way to optimize yet even further. With the ability for users to move in and out of multiple OS's seamlessly will nearly end all compatibility reasons when upgrading to a new OS. So for Vista or even Windows Seven, it's just a matter of running side by side, IE 6 with IE 7, XP driver or Vista Driver ect. Also, deploying OS will be a matter of streaming down just the delta blocks of the OS that aren't already there using Http. For mobile users, being able to package the entire desktop environment onto a USB drive can be useful. Also using vDNA, this will change things in how we manage user data in the future. So sort of think how things work when connected to a Citrix/TS session, except if there is ever a disconnect in the network, the user still has his desktop!

Finally, Live Mesh is shaping up more and more to being that virtual desktop in the cloud. Microsoft is really putting a lot of work behind it to develop it into something more that just a offered service, but an actual functional platform. So one day, we all may be working from a browser to connect to our virtual applications via mobile device or thin client. But that's just silly, where am I going to put my DVD movies...oh yeah, I'll connect my mobile device to my Microsoft MediaRoom and stream movie or TV via IPTV. I sure see the desktop becoming the mainframe of yesterday!

Client Roaming in Application Virtualization 4.5 (Softgrid)

twilch — Sun, 25 May 2008 04:04:00 GMT

Coming from the days of implementing Softgrid versions pre-4.5, there were complications to setting up Softgrid in a large scale environment. The infamous ability in Softgrid to allow roaming users in all parts of the globe to receive their assigned applications instantly on any computer at login was an big sale among many organizations. But when deploying it, there was much work entailed to accomplish it. How do you control all these applications from streaming across your WAN links? How do I lock it down to pull from local server resources? Let me explain the progression of the versions here:

Pre- Softgrid 4.5:

In versions 4.x, Softgrid was great in centralized environments with high bandwidth availability. But in most large environments, there are branch sites you need to plan for. So where does the client stream the SFT file from? If the client is in Site A and moves to Site B, does it pull the package from Site A still? These are all sore questions to answer during your planning stage. There are different techniques to use to pull locally.

DNS- In DNS, there is a setting called Netmask ordering. It allows clients on a local subnet to pull from a local resource by giving the client the nearest IP for that subnet. So with multiple DNS host entries named "SGserver" pointing to each of the branch VAS IP's, a client when looking for SGserver would receive an answer for it's local subnet IP. This works great but their are some gotchas with clients caching the last subnet after it has moved though.

DFS- Using DFS, you can also get around where clients pulled their content from local DFS locations. Using this method, you need to have all of your AD sites and services Subnets defined. Plus you need to have separate AD sites and services setup if multiple domains. (with one domain and using windows 2003 global catologs, there really is no need for all the setup anyway's)

Softgrid 4.5:

Now we have some scalability choices that we did not have before. Here's some of these new changes:

ASR- Application source root is a big addition to the 4.5 version that allows direct manipulation on where a client streams the SFT from. It's a registry key that can instantly override the HREF path specified in the OSD. So for this, use the provided administrative template (w/RTM) to set the ASR in a GPO at the site level. So when a computer moves around and starts up, it'll receive an ASR path through the GPO to the local content location. Love this flexibility.

OSR/ISR- Like the ASR, these can be set for the ICO/OSD files as well. During EACH DC refresh, the client pulls all the ICO/OSD files down which could very well be from across the WAN. So if a user clicks the reload/refresh button 10 times and he has 20 virtual apps assigned, it can add up against your traffic. So now you can also control where those ICO/OSD files are brought down from.

ConfigMgr R2- With this new integration, Softgrid works off the backbone of ConfigMgr's enhanced scalability features. This has really become a solid solution for folks wanting Softgrid and have ConfigMgr in place.

When a user clicks an icon file to stream a virtual application, the v-launcher or interceptor talks to the Advanced client which from it's management point, receive the location of the closest virtual enabled distribution point with that SFT and streams it from there.
Since ConfigMgr now included 'Branch office' distribution points, a windows client can become a Softgrid storage point when no servers are available. Thus, clients at these serverless locations can also pull virtual applications within their own subnets.

Lastly, with ConfigMgr's ability to deploy applications via the internet when in it's Native Mode (PKI certificates), this also includes virtual applications. The streaming delivery would not be able to work in this scenario, but a download and execute local delivery would allow these virtual applications to deploy, even if the user is connected at a Starbucks.

So as you can see, there are new options that help make this product more enterprise ready. I'm looking forward to implementing 4.5 with these new scalable enhancements to achieve a more dynamic solution.

Troy

Virtual Application Delivery and Launch within ConfigMgr R2 - Part 2

twilch — Sun, 25 May 2008 04:02:56 GMT

Ok, in the first part of this series, we looked at how these virtual applications are delivered from ConfigMgr R2, next we should look at how to actually deliver them and what is happening in the background while the magic is happening. Now the complete visual in "How To", I plan on doing a blogcast and posting up. Much easier to demonstrate by video and more effective for the visual style learners like myself out there. So let's look at the high level steps.

Streaming:

Before the application is delivered, the virtual application content is staged to the selected distribution points. After these DP's are updated, next comes package registration.

The ConfigMgr R2 client evaluates the advertisement (policy) and discovers that the virtual application is being deployed for streaming. The ConfigMgr client then registers the virtual application package with the Softgrid client (yes, you have 2 individual clients here, ConfigMgr R2 & Softgrid). Once registered, the icons show up on the desktop, start menu Quick launch where ever configure for the user, but the application is not physically there anywhere on the system yet. Only the shortcuts are added to the client computer.

Next, the end-user launches the application through a shortcut. This creates a connection to the streaming DP and then the application is served up, on demand, to the user.

User clicks a shortcut to launch an application.

Shortcut calls the SCCM launcher

Launcher talks to the Advanced client.

Advanced client talks to the MP and performs a location request.

Once the DP location is established, the Advanced client sets the source URL for the package. This part is slick in that it dynamically changes the location no matter what the HREF path specifies.

Adv Client hands off to the Softgrid client for Vapp streaming. From there the normal Softgrid actions to stream take over.

Local Delivery:

When advertised, the virtual application package and its contents are moved across the wire using BITS from the distrubution point to the client computer.

Next the ConfigMgr R2 client evaluates the advertisement and discovers it is a download and execute policy. On policy activation, the content for the package is downloaded to the clients local ConfigMgr cache. Then the ConfigMgr client registers the virtual application package with the Softgrid client referring to the local copy of the package(not a copy on any streaming server). Once registered, the icons show up where they were configure to. At this point the package is local on the system and can be used immediately without any connections required.

Next, the end-user launches the application through the shortcut which creates a connection to the local copy of the package (File://<path>)

Package Upgrade:

The Softgrid package is revised with a new update to the virtual app package

Next update the source content in the ConfigMgr console and then update all DP's that it is currently begin distributed to. Cool part is next.

ConfigMgr now uses Binary Delta Replication(BDR) for both a 'site to site' transfer and a 'site to DP' transfer to update these packages. So just like a WIM file, the smallest binary changes inside the SFT file are all that is copied over.

The advertisement gets re-run.

Now with streaming delivery, the next time the end-user launches the application, the server will deliver the updated virtual application.

For Local delivery, changes are downloaded via BITS and BDR to the local ConfigMgr cache and then applied to the Softgrid FSD cache when they are completely downloaded.

Virtual MSI's (Standalone):

Well, what can I say for this delivery method. This basically requires you to treat the package as a new MSI package to be delivered through normal distribution methods.

Hope this was informative on how the delivery of these two great products melded together to form something no less than incredible. Taking the backbone infrastructure of ConfigMgr and combining it with such dynamic optimization like Softgrid, better together at last!

Next I'll talk a little about the extended scalability that Softgrid 4.5 will bring us outside of that in ConfigMgr R2.

Virtual Application Delivery and Launch within ConfigMgr R2 - Part 1

twilch — Sun, 25 May 2008 04:01:55 GMT

After spending many hours in my virtual labs testing and learning the new changes and integration of Softgrid (*cough..Microsoft Application Virtualization) with System Center Configuration Manager R2, I'm finding there are essentially 3 ways of delivering virtual applications. So I'll go over and cover the processes I've taken to successfully deliver them. The 3 are Streaming, Local delivery and MSI.

Streaming:

When the app is advertised to stream to the client, the client uses the Application Virtualization Server (lightweight component installed on the Distribution Points). Then the Applications shortcuts invoke a connection to the server in order for the app to be delivered and used. This delivery is great for your desktop systems that are highly connected clients. One of the best benefits I find using this method is, when the application is upgraded, it's applied to these Virtual enabled DP's and the clients connect to the new version on the server fast and seamlessly.

Local delivery:

In working with SMS/ConfigMgr, this method is best known as the download and execute with BITS. The client receives the virtual application package content locally. Unlike the traditional method of stream from a server, the application shortcuts refer to a local copy of the Virtual app. This is great for your laptop systems that are frequently offline or for slow/unreliable networks. It does use BITS which is good in case a partial download has been delivered and it also uses Remote Differential Compression to send only the binary deltas when the virtual application content is changed or upgraded.

MSI (virtual):

These are essential MSI's we all know and love and work well with any type of ESD solution. Using either the MSI Utility (which creates 4.2 version MSI's) or the 4.5 sequencer, you generate an MSI based virtual application that can then be imported into SMS 2003, ConfigMgr RTM using the package by definition package. Then it is advertised to a collection. The disadvantage to using this is the inability to have the dynamic upgrades. Yes there still is the original files and the SFT is loaded into the Softgrid cache 100%. If an upgrade is needed, you must re-create the MSI, update the DP's and re-advertise it back to those same systems. Much like is it today. You where's the advantage with that? Well, the app is still virtualized, thus defeating the compatibility issues with some apps and it's much cleaner on the system since file and registry changes are not made. I will write more on this method (standalone) in another blog since there is a lot more to this.

In part 2 I will cover the actual steps I used to perform these deliveries and go into a little more detail in what actually takes place on the server and client.

Got Mesh!

twilch — Sun, 25 May 2008 03:56:38 GMT

There's a new technology verb in town. Google's has 'Google it'. Now I can see the term 'Mesh it' or 'Go to my Mesh'.

Microsoft has really raised the bar with this new technology that I can see exploding for all users with multiple computers or always on the go. Cloud storage has been out for a bit and has been convenient at times, but not really something that changes my everyday interaction in computing.

Live Mesh does just that! Part of the Live family, it has a client that you install on all your devices that you want and by doing this, it enables you to connect to any of those machines through web browser anywhere you go, even behind firewalls. I know you have others that do this too, but it doesn't stop there. It adds a context menu item so that any file you want to synch into the cloud, it's a simple click. Immediately it synchs to all your devices for availability. You also get a Live desktop which is somewhat like a virtual PC in the cloud(well, very limited at least). Then there's the MS Office Groove like features where you can share certain folders so that when any of those connected family or friends add files, your Messenger like applet displays the change.

This is something by Live that I see going places. Unfortunately it is still in beta and limited to storage at the time, so on Microsoft connect, it is a submit and wait for invite to be able to use. For more info on it including some must watch videos, check it out here:

https://www.mesh.com/Welcome/LearnMore.aspx - Learn more about it in the "See it in action links"

http://on10.net/blogs/nic/Hands-on-with-Live-Mesh/ - Live team show's it in a real world example

http://blogs.msdn.com/livemesh/archive/2008/04/21/live-mesh-as-a-platform.aspx - From a developer view as a platform which shows it has potential

http://www.mesh.com/Welcome/TourDeveloper.aspx - And lastly, for a deeper look from behind the curtain.

Is this Ray Ozzie's new Groove? I think so!

http://scobleizer.com/2008/04/22/ray-ozzie-delivers-with-live-mesh/

Troy