The recommended practice is to choose a virtual drive assignment and stick to it; commonly, this is drive Q: - so what happens if you want to change to something else, for example, V:

If all applications were equal and followed recommended practice, then simply changing the environment variable %SFT_MNT% on the client would enable you to change the virtual drive at will and no applications would need to be re-sequenced; however, not all applications are equal and this can cause some issues.

Some applications hard code the installation drive in the registry or configuration (INI) files - This means you have several options:-

1. Re-sequence the application to the new virtual drive letter.
2. Sequence the application to the C: drive (be aware of the performance impact of doing this)
3. Manually edit the applications registry entries or configuration files

As with all applications, if you decide to have a different client virtual drive compared to the sequencer then testing will be paramount.

Compressing or not compressing during sequencing has benefits and disadvantages:-

Compressed. The sequenced stream will be smaller; this can be useful where storage is of concern, or more probable, where the network utilisation is of concern. Compressing the sequence reduces the quantity of data streamed over the network to each client machine, this means it will be delivered faster and utilise less bandwidth.
The disadvantage of compressing is that the decompression on the client computer is processor intensive and can increase the initial launch time.
If you plan to use compression it is recommended that testing on the lowest performing target machine is performed to ensure acceptable usability.

Not Compressed. This is the default and recommended unless the network is deemed excessively slow.

TIP: bZip2 uses less processor cycles to decompress than zLib and is therefore uses less power, is faster, and can process more data, this has the benefit of a higher bandwidth throughput. Testing should always be performed to optimise for your scenarios.

Block Size
Block size is specific to Feature Block 2 (FB2) as feature block 1 is streamed as a single entity. When the client requests data from FB2, the size of each block determines the amount of data that can be streamed in a single transaction. The larger the block size, the more data is streamed in one transaction and as a result, network utilisation is increased; for smaller block sizes, less data is streamed in one transaction and this reduces the network utilisation.
There is a balance needed between large and small block sizes where the amount of data in any block compares to the request of the client. Larger blocks can contain more useful data in one block, but this may be more than required, whereas smaller blocks are more likely to contain the useful data but more will be required and each has a network overhead. Over the years of testing with SoftGrid, the default 32KB has been found to be the best balance of the two.

TIP: Block size can directly influence compression using bZip2 and zLib and should be tested using different block sizes when compression is used.

The simple answer is Yes; as long as the end point machines have the SoftGrid client installed.

The longer answer is that this opens a minefield of questions; fortunately, we have the answers. Here are some common questions:-

• Can we establish a level of trust with unknown machines?
• Can we differentiate between a corporate laptop, customer site, home machine, or kiosk? 
• Can we restrict access to our domain only, or a customer domain?
• Can we allow for access to a specific subset of SoftGrid applications based on user and location? 
• How can we stop application layer attacks, buffer overflows, worms?
• Do we need two factor authentication in order to securely log a user in, are there alternatives?
• Are users leaving important data/documents behind in the browser cache, temp file directory, or other locations on the hard drive on non-corporate assets?

SoftGrid requires some assistance to answer these questions, the Intelligent Application Gateway (IAG) http://www.microsoft.com/forefront/edgesecurity/iag/default.mspx

IAG’s killer features for SoftGrid are the End Point Engine and Application Layer Firewalling/Intelligence.  Combine these and you can do pre-authentication security screening, determine level of trust, provision access to SoftGrid resources allowing only predefined valid calls, and delete user footprints post session.  And all this is done over SSL.

Using IAG also gives you the ability to answer some more fundamental questions:-

• If the machine is a Kiosk should we just give the user a Terminal Services session instead?
• If the machine is not a corporate machine, but is on our network, should we use SoftGrid?
• If the machine is at a partner
• If the machine is mobile (3G connection, high latency) should we stop SoftGrid updates to the cache?
• If the machine is a corporate laptop at home should we give them full access to the network?

Once you know how you're going to provide the corporate services to any end point, IAG and SoftGrid can provide the technological solution.

The sequencer, virtual or physical, should have two partitions (or disks), the first, normally C: is for the base build, and the 2^nd, normally Q: is for the installation of the application to be sequenced.

Sequencing is a very disk I/O intensive operation. Where performance is required (for example, multiple or batch sequencing), it is recommended that focus is placed on the disk architecture. For example, use SCSI over IDE or SATA channels, or use fiber channel.

If you're using a virtual machine, separate drive C: and drive Q into two separate virtual disks (not partitions) and place each on a separate host I/O channel to spread the load.

Free disk space should be at least three times the requirement for the application installation. One for the application’s installation files, one for the resultant package’s file, most notably the . SFT file, and one for any temp files generated during the Sequence.

Can you sequence games? You bet you can; although how useful that would be in business I don't know. In contrast, in my early days, I used games such as Solitaire to teach beginners the basic principles of the interface, mouse, drag n drop, etc.

Pacman is one of my all time favourites and I spent many an hour playing this in the pub and so I decided to sequence the game to see how it coped.

I chose Pacman because it was a good starting point for two reasons.

1.     It does not require any special hardware (DirectX10 for example) or disk protection systems.

2.     It wasn’t designed to run on Vista, so to really test it, I used Vista virtual machines for the sequencer and client J

The sequencing went very smoothly, Pacman Installed and ran without flaw, as it did on the Vista machine.

Although Pacman is a simply game it does demonstrate that even programs developed many years ago, not intended for the Vista platform, can easily be sequenced and deployed.