AutoIT is enterprise ready!?
In IT everybody i meet always has something against AutoIT, this is for a obvious reason you don’t want to use recorded mouseclicks or sendkeys to install your applications unless there is really (no really!) no other option left.
In everyday usage i use AutoIT to create most parts of Login VSI, its perfect for emulating the user workloads because it works like a real user and because i dont have real programming skills the rest of VSI is also created in AutoIT script.
You would think a large company would do this a little different, maybe they would create the workloads in AutoIT scripts but creating the configuration GUI’s would be done much more professional…. Well VMWare dissagrees 
apparently.
Conclusion: +1 for the AutoIT team and –1 for VMware!
Citrix Edgesight will break march 25th
Well it’s always nice to know when you production environment will break, i wish i knew this for all software running in my environment 
. But it doesn't look really professional from the vendor side. And this time the vendor is: Citrix!
As of 2010-03-25 (March 25th, 2010), EdgeSight 5.0 and 5.1 (all service packs) will stop functioning.
Customers will receive the following error message for payload uploads:
“Archive load error: The archive '/edgesight/app/suser/ZRemoteLib.zpd#12!lsync.htm' is not appropriately signed. The system cannot find the file specified.”
General symptoms: Payloads will not be uploaded and many of the EdgeSight components will not work properly resulting in different errors.
Congratz to Citrix for reintroducing a bug the already discovered in version 4.5 of their software product!
App-V Self Support Tool
We all remember the last tool created by Peter Nap: App-V on a stick, but Peter didn't stop there. Yesterday Login Consultants released a new tool: The App-V Self Support Tool. One of the things that you will find out early on when actual users start working with App-V, is that sometimes they manually need to reset, preload and refresh their virtualized applications. As a result, you will need to give users access to the App-V client MMC plug-in.
The problem is, the MMC is typically off-limits for normal users in the enterprise because of security policies on desktops and laptops. And even when users have access, try explaining non-technical users how to work with the App-V client MMC plug-in. The App-V client configuration is simply way too clunky for normal users.
The great thing about the App-V Self Support tool is that is consists of just 2 files that do not have to be installed, one executable and one XML file for the configuration. This makes enterprise deployment quite easy: just drop the files anywhere on the client and provide the users a shortcut to start the application.
The interface is deliberately simplified, so users can find their way around. There are only a few options: View, Language, Repair, Cache, Start and Refresh. Users do not need anything more, and more importantly, they are not required to ask the helpdesk to support them.
Download the App-V Self Support (App-V SST) tool here.
[Virtualizing the App-V Support tool is not recommended! (No really.. it breaks)]
How to suppress the Open File Dialog (zone checking)
If you use scripts for all kind of automation purposes, you definately have stumbled upon the issue that when you run the script, which in turn calls an executable file from somewhere on a network share, you get prompted with a Open File Dialog. Very annoying when you just want your script to run silently.
Fortunately there’s a workaround for this:
Change the SEE_MASK_NOZONECHECKS environment variable
Within your script, temporarily change the SEE_MASK_NOZONECHECKS environment variable to 1.
Note Do not use this as a permanent system environment variable because it will disable all Zone Checking.
VBScript example:
set oShell= CreateObject('Wscript.Shell')
set oEnv = oShell.Environment('PROCESS')
oEnv('SEE_MASK_NOZONECHECKS') = 1
oShell.Run 'somecommand',0,True
oEnv.Remove('SEE_MASK_NOZONECHECKS')
Note: I replaced all double quotes with single quotes in this example because of the syntax highlighting, if you want to use this example, find and replace all single quotes ( ' ) with double quotes ( " )
Powershell example:
$env:SEE_MASK_NOZONECHECKS = 1 somecommand.exe Remove-Item env:\SEE_MASK_NOZONECHECKS
WBEMTest: Handy tool for testing your WMI Queries
When you are working with deployments, whether it is SCCM, MDT, Altiris, LanDesk or whatever tool you are using, or you’re building a script which uses WMI queries, there’s always some actions you only want to perform on certain computers. In SCCM and MDT there’s builtin support for WMI queries. For instance, you want to apply a mass storage driver only to a computer that has that controller present.
To build these WMI Queries, in the past I always used the WMIC commandline tool. A very handy tool, but the syntax for this tool is a bit different then your average:
SELECT * FROM Win32_ComputerSystem WHERE model LIKE ‘%DC7900%’
In WMIC this query would be translated to:
WMIC PATH Win32_ComputerSystem WHERE “model LIKE ‘%DC7900%’
For this particular query it’s not that different, but what if you only want to get certain values?
SELECT Model FROM Win32_ComputerSystem WHERE model LIKE ‘%DC7900%’
Would be translated to:
WMIC PATH WIN32_ComputerSystem WHERE “model LIKE ‘%DC7900%’ GET model
As you see, it’s not really hard translating the commands, but there’s an even easier way to get your WMI Queries
Use the builtin Windows Management Instrumentation Tester: wbemtest.exe
Start>Run>wbemtest.exe
Click on connect and type the namespace you want to connect to: (Default for WMI is root\cimv2)
Now we have all sorts of buttons available… we can easily open and explore a class and see it’s methods and properties… we can create a query in the syntax of:
SELECT * FROM Win32_ComputerSystem
Happy exploring and testing with WMI
Powershell 2.0 can now be downloaded
As part of Microsofts Windows Management Framework, Powershell 2.0 is now available for the various Windows OSes. Download it from http://go.microsoft.com/fwlink/?LinkID=151321
XenApp Maintenance
Today I spotted Martin Zugec posted an article about S4matic, which I am currently working on together with Martin. To take a look at how S4Matic can help you with your XenApp maintenance look at this brilliant article by Martin Zugec!
Installing WAIK unattended
Today I was thinking of creating a sort of “master” script for MDT implementation, that would install and configure MDT2010 unattendedly. So ofcourse, my first order of business was installing all the prerequisites unattendedly… and that’s where the trouble started…. Microsoft does not support installing the WAIK via the well known /qb-! or /qn switches… because of the EULA you have to accept. I found this great article by Richard Smith on the deployment guys blog. Unfortunately for me… my script will be running under a system account (SCCM)… which means no UI at all… so the Auto-IT method didn’t quite do it for me…
So I decided to go old school, whip out my favourite MSI editing tool: Orca and create a transform that removes the Full UI requirement.
Now all you have to do is: msiexec /i waikx86.msi TRANSFORMS=waik.mst /qn and voila… fully unattended WAIK installation…
Disclaimer: This is very much NOT supported by Microsoft… so use at your own risk.
Small workaround when Clear PXE advertisements doesn’t seem to work
I find it very annoying that sometimes when I clear an PXE Advertisement from the SCCM console and I reboot the machine I still get the PXE Boot Aborted message… a small workaround I always use is the following.
- Clear the PXE Advertisement using SCCM console
- Stop the WDS Service on the SCCM PXE Server
- Clear RemoteInstall$\SMSTemp on the SCCM PXE Server
- Start WDS Service on the SCCM PXE Server
And voila! The advertisement does work this time around…
All in all I have experienced a lot of troubles with PXE and SCCM… I am really hoping the next version of SCCM will bring major improvements to this part….
Creating a custom boot image for SCCM SP2 (WinPE 3.0)
Today I had to recreate my x86 boot image in my SCCM environment. I had just upgraded my testserver to SCCM SP2 and found that the old way of creating a boot image didn’t work anymore… seeing as SCCM SP2 uses DISM.exe instead of imagex and peimg. So I went looking for instructions on creating a custom SCCM SP2 image, but couldn’t found any, so here are the instructions .
1. Start the Deployment Tools Command prompt and enter the following command:
COPYPE.CMD x86 1 c:\WINPE
When you're working on a 64-bit WinPE image use "amd64" instead of "x86"
2. Mount the winpe.wim file to the mount dir that’s created automatically:
DISM /Mount-Wim /WIMFile:c:\winpe\winpe.wim /Index:1 /MountDir:C:\winpe\mount
3. Add the packages required by SCCM to the wim (again, if you’re working on 64-bit Windows PE substitute "x86" with "amd64")
DISM /Image:c:\winpe\mount /Add-Package /PackagePath:”C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-scripting.cab”
DISM /Image:c:\winpe\mount /Add-Package /PackagePath:”C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-wmi.cab”
After this step you can continue adding packages (such as winpe-hta.cab and winpe-mdac.cab) or custom files to the boot image. The 2 packages worked out above (Scripting and WMI) are required by SCCM, without these packages you will receive an error during updating your boot image to the distribution points.
4. Commit the changes to the WIM and unmount the WIM
DISM /Unmount-Wim /Mountdir:c:\winpe\mount /commit (thank you for the correction Matt!, It appears as if I was quite sleepy when I wrote this post
5. Import your custom boot image into SCCM.
That’s it, just as simple as it was with the previous version of WAIK, only different commands