Application Packaging, PowerShell

Running an .exe from a path with a wildcard in PowerShell

It’s been a while since I have posted anything and there is no shortage of topics for me to catch up on. I am going to start with a problem I was working on the last couple of days. Here is the scenario:

I was tasked with packaging the installation of an application that was previously installed manually by the users of the environment I am working in. When the users installed the application from the vendor’s website it would get installed in each user’s appdata folder. The version I was given to package was designed as a per-system install. They also wanted me to remove the per-user install before installing the new per-system version. After creating the package for the new version, the issue became being able to uninstall the per-user version. The install was not an MSI and the vendor’s method for uninstalling was an uninstall.exe file located in the appdata folder where the application had been installed for the user. This is obviously tricky because depending on which user installed the application it could be located in any random user’s folder path. I’ve been using PowerShell for my primary scripting language for most application deployments for some time now, so the key was finding a way to do this in PS. My solution was as follows:


First I set a variable for the path with my wildcard. I used the cmdlet resolve-path so that the variable would have the value of whichever user had installed the application I was trying to uninstall by searching for the uninstall.exe in the application folder.

$AppUserPath = Resolve-Path "C:\users\*\AppData\Local\AppVendor\AppName\Uninstall.exe"

Then I created an if statement that would test for the resolved path if it existed and the remove it

If (Test-Path $AppUserPath) { Start-Process -FilePath $AppUserPath -ArgumentList "/S"}

So all together it looked like this:

$AppUserPath = Resolve-Path "C:\users\*\AppData\Local\AppVendor\AppName\Uninstall.exe"
If (Test-Path $AppUserPath)
{Start-Process -FilePath $AppUserPath -ArgumentList "/S"}

So now when my script runs, it will parse through all the user appdata folders on the machine and find the one with the application installed that has uninstall.exe file. Then it will execute the uninstall.exe file using the resolved path that it found. After that installing the new per-system version was a piece of cake

Amber, Application Packaging, Application Virtualization, How-To Guides

Application Compatibility- A Process Overview

It seems almost a forgone conclusion to most home pc users that Windows 7 is in their homes and Windows XP is just a tale to tell the grandkids. But for many corporate and IT environments Windows XP is still alive and kicking….at least for now. Windows has set a date to end support for Windows XP on April 8th 2014. It’s a big deal to switch from one OS to another the corporate world, and expensive too. One of the most important and stressful parts of that migration to a new OS is application compatibility. Applications have come a long way in the past couple decades…and believe it or not companies are still using applications that are sometimes older than the tech support team trying to support them. Back when Windows XP first came out software companies kind of did their own kind of thing when it came to designing how their applications were installed and functioned on a computer. They didn’t care about playing nice with the OS or the other applications that may get installed on the same machine. What resulted was a very messy bunch of hacked registry files and system files that caused more blue screens of death to be funny. So when Microsoft design Windows 7 they decided to firm up what software was allowed to do to the OS. There is a limit to what changes can be made and which files can be accessed by applications being installed on a pc. For software that was designed before Windows 7 this can lead to complete failure…so what do you do? If you are the system administrator or application manager for an organization where do you start?

Application compat process overview

The above graphic shows the compatibility process an application must go through when getting ready for Windows 7 from XP or from a 32bit OS to a 64bit OS. Both types of migrations bring along with it compatibility concerns that could potentially bring a company’s productivity to a screeching halt. Lets dive a little deeper into each step of the process to understand what is really involved. We will use a Windows 7 migration as our example in the following information, however the steps for compatibility from 32bit to 64bit OS or to Windows 8, etc are the same.


I cannot….I repeat cannot stress how important a proper inventory is. If you don’t do a complete discovery of the applications in your environment you will might be able to get off the ground running but you will end up flat on your face. When doing a discovery you should not only be looking for the major application products that you think your organization uses, but also the ones that your users take for granted. This can be small programs like 7zip or VLC player. Since they are free these tools can sometimes be overlooked. Even more overlooked however is the dependencies for all of your programs. Usually you dont notice them because they install automatically with your main applications, but some of them don’t even show up in your programs and features(add and remove programs from XP). If you don’t test not only your primary applications but your dependency applications as well you will be in a world of hurt. Additionally, if you don’t discover as many as these little buggers as you can early on you will not budget your time or money for your migration project correctly. It’s the difference between you think you have 150 applications and 400. So if you don’t want to start a project telling your bosses that its one price only to get started and discover it will cost you triple, its important to do a proper discover of ALL the applications in your environment. Microsoft provides a tool to help you discover your applications as well as some more information about your environment called (MAP) or (Microsoft Assessment Planning) Toolkit. For information on that tool please see the information available on Microsoft’s product page.


Now here comes the tricky part. There are a couple of ways of analyzing your applications for compatibility issues. You can hire programmers to debug you applications one by one on your new Windows 7 image to find the issues and try to remediate(fix or put a band-aid on) them. This would be a possible option but not probable, considering the man hours and cost involved of taking this approach. You can use Microsoft’s compatibility toolkit otherwise known as (ACT) or (Application Compatibility Toolkit).  You can have a team of employees who know what the applications are used for analyzing the applications to see if anything errors out or doesn’t function correctly. This method could be cheap but leaves you with no guarantees of what will really work and what might or might not break when in production. There are also a few third-party compatibility analization tools out on the market. The top two being Citrix’s AppDNA and Quest Software’s Changebase. These two products will give you a RAG status and a report as to what compatibility issues it has found. They each have different modules and versions based on what you want to analyze and pricing to match. (From personal experience at the time of writing this blog my opinion is that AppDNA gives more detailed reporting than Changebase, but you will want to check out what the current features are to make sure which tool is best for you if you decide to use one.) No matter how you analyze your applications you will want to be able to sort them into three main categories. These categories are usually referred to by their compatibility status of Red, Amber, or Green. Red applications are ones that have serious compatibility issues resulting in application failure or malfunction. Generally if you application falls under this category is considered high unlikely to work well on Windows 7. Amber applications are ones that have some compatibility issues but are generally able to be fixed to work properly in a windows 7 environment. Green applications are either free from compatibility issues or if they have any issues at all they do not impact the functionality of the app.


Once you have sorted out the compatibility status of your applications you can spend some time testing them on your environment and remediate any issues you can through repackaging, scripting, virtualization, or some other means depending on what the issues are and how your IT team would like to approach fixing them. (It is not uncommon for some IT departments to make their own rules about which compatibility issues they are going to try resolve and which they will ignore assuming they will not impact functionality to their users by ignoring them.) If you have done your discovery and analyzing properly you should have a good idea before starting testing and remediation which applications will need work, which applications can do to the next phase of the process, and which applications will need to be mitigated. It is also recommended at this phase to do a UAT test or a User Acceptance Test. This is a chance for someone in your organization who uses the application you are testing on a regular basis to try the app if you have made changes or not and see if the user experience of the application installed on your new OS environment will work correctly and function as needed for production use.


Mitigating applications

So what do you do if you applications wont work on your new environment and can’t be remediated? You mitigate! As it shows in the graphic above there are few options to look into when trying to figure out what you can do with applications that are absolutely not compatible with your new OS environment. You can check with the software vendor for new versions, you can have a programmer recode your application with the fixes you need. You can try desktop or application virtualization, so when it comes down to it if you really can’t live without that application you got when you where still running Windows 98 you might still be able to get it up and running on your new OS environment. Microsoft has also provided a toolkit for doing some forms of mitigation as well called the (MDOP) or (Microsoft Desktop Optimization Pack).

So now are you ready to begin your application compatibility journey????? Well if you are looking for more detailed information to any and all of what was covered above look for more posts from If there is something specific about compatibility testing or other topic you would like to see featured here send us an email or connect to us on Facebook or Twitter.

Happy AppCompat Testing!

Application Virtualization, Red

App-V 5.0 Beta: A Change is Brewing

What’s going on?

It’s all over the web; virtualization and packaging bloggers are all offering their thoughts on the new changes to App-V in Microsoft’s latest beta 5.0.  For those not familiar with App-V or Microsoft Application Virtualization, there are definitely more resources on the web to learn about it than there were back when Microsoft first acquired the software from Softricity when it was known as Softgrid. For more basic information on what App-V does straight from the horse’s mouth go here.

Let the Changes Begin:

  • The sequencer no longer uses the CSIDL to parse files and path information but instead a new VRG with is a specific syntax to App-V.
  • The file format has changed from .pkg, .sft to .appv. This is also an App-V specific format that will move App-V from block streaming to a compressed folder format. The new format effectively removes the 4GB package limitation of the current version of App-V. (Can someone say virtual Adobe Suite, AutoCAD and many more?)
  • OSD files are gone too. Since the new file format and virtual package system allows for the application shortcuts to point directly to the exe file instead of the App-V client the XML configurations that the OSD held are no longer needed.
  • Because of the way the virtual application configurations are controlled using the new format both per user and per machine configurations are supported for an application at the same time.
  • The MMC console that was previously used to manage published apps is now replaced by a web-based management tool that is based on Silverlight.
  • Because of App-V now using the industry standard web servers to publish applications they will no longer need to restart downloading if interrupted. Instead they will continue once reconnected and download only the remaining files that need downloaded

If you want to play around with all the new App-V software without having to download and install it all yourself you can visit Microsoft’s Virtual Lab. It’s not without its bugs and sometimes the screen resolution on the remote machine can be annoying.

Here is idea of how the new App-V system communicates:

Screen Shots of the new parts of the App-V software bellow:

Sequencer screen shots

Client Screen Shots:

App-V Server:

My 2 Cents

I’ve worked with App-V since the days of Softgrid and have always been interested how such technology will be able to make a serious impact not only on a corporate scale but in the private sector as well. With the new changes Microsoft is making to the virtualization technology I think we are heading into a new paradigm when it comes to application packaging. There are still limitations that will make traditional MSI packaging necessary, however the architecture level integration of App-V into the Windows OS will make virtualization very attractive. The security and management options presented by App-V are enough to make corporate IT managers excited. Although it is still in beta App-V 5.0 presents us with the leap forward Microsoft and virtualization technology really needed to not only be taken seriously but give our old concepts of application packaging and management a run for its money.