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 SizeBlock 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.
No. Once a computer is using virtual applications deployed in this way it can not longer 'switch' back to streaming mode. By 'switch' I mean run in mixed-mode or easily go back to streamed mode. The client will either work in machine context offline mode, or server based streaming mode; it will involve several steps to change the client back to streaming mode, including removing the v-applications deployed from an MSI package.
The new offline capability is not just the MSI Utility, it is also an update to the SoftGrid client.
The new MSI Utility has been announced (formally WiAVE); check out the product teams' blog here and for more information on client side application licensing see my blog entry here.
Using the MSI Utility we are now pre-caching the virtual application (plus a few other niceties) and it is now classed as 'installed' on the client computer; therefore, you need a license. If you distribute an application to 5,000 computers, you need 5,000 licenses.
To Compare:-
You should contact your product vendor for their specific licensing implications.
The new offline mode of the SoftGrid client means it won't be contacting a SoftGrid server for authentication, this also means that the SoftGrid server can't monitor the client and central license checking it not available.
There is a simple answer to this, and of course, a more complex one.
Simple answer.
No. The virtual application is read only and cannot be infected once it has been sequenced.
Complex answer.
There are several places a virus or malware can be introduced, let’s take a look at each of those areas.
The Sequencer. If the application media or the sequencer contains malware or a virus, then the sequenced application will probably be compromised, and as such will be distributed to the clients. Best practice for the sequencer is that it is in a known and consistent state, this means it is a base or core build, pre-scanned for viruses and malware (the scanner should be disabled for the install). You can scan the sequencer either online (using the latest signatures before any sequencing) or if it’s a virtual machine, it can be scanned offline by mounting the file system. The installation media should also be scanned, either by installing on a virtual machine and scanning or by using media that is already deployed in the environment.
Therefore, the answer to, “can the sequenced application be infected” is No. Theoretically it can, but I’d be far more worried about the rest of the environment if the basics were flawed.
SoftGrid Application Primary Cache. This cache is the local version of the streamed application; it is read only and in a proprietary format. This could only be infected by streaming a compromised application. See my point on The Sequencer.
Therefore, the answer to, “can the client global cache be infected” is No.
The Users Abstraction Cache. This is the machine global update cache and contains updates from the client machine (the PKG files; also known as the "personalisation abstraction layer"), for example, a user reads v-Outlook email and it wasn’t sequenced with RMS, they go to the Internet and install RMS – this component is kept in the update cache. This is read only once it has been created. This cache can be infected by one of two ways, 1. The source update was infected, or 2, the host machine was infected (see next section). Again assuming reasonable protection is in place and users are not downloading infected updates throughout the company, then point 1 is mute.
Therefore, the answer to, “can the client global update cache be infected” is No.
The host operating system. If the host operating system is infected with a virus or malware then several attacks try to happen. For a virus; if the application is not running, then the virus can not see it (as it’s not actually installed) and therefore can not attempt the infection; if the application is running, the virus will attempt to infect the application and fail as it cannot gain access to the systemguard environment, it may however add itself to the abstraction cache as an update. Another example, is a chain mail virus that kicks off and looks to attach to v-Outlook. It tries to launch the .EXE but can’t as it cannot see it and it can’t connect to view it’s address book etc.
If the attack is malware (for example, an macro) then it has the same restrictions as a virus, it cannot alter the contents of the systemgaurd environment and any changes to the binaries are stores in the abstraction cache, see picture below. The difference is that although the macro is instantiated by the virtualised application it can alter the host machine, for example, it can alter DLL or executables on the host. It should also be noted that any Malware running within a virtual environment would still be a real Process in Windows; Thus, that process will be monitored by the Active Anti-Virus/Malware scanner and all the malware attempts at writes would also be monitored.
This type of infection is actually nothing to do with SoftGrid, however, in these scenarios, SoftGrid offers additional protection and several new recovery abilities, namely the resetting of the application to the core cache and the ability to re-populate machine instantly.
But what if something goes wrong and all your risk mitigation and precautions fail. Then, If the host is infected and has infected the Abstraction cache, you can simply clean the PC and reset the SoftGrid client cache (user can do this if required). If the sequenced application is infected, simply resequence, replace the virtual application file on the server or increment the version.
I noted an issue yesterday where an application took over 40 seconds to launch on a Windows Vista client. After the usual investigation methods (was it sequenced on Vista, is the Cache ok, running performance monitoring tools, event logs, SG logs, etc) it was realized that the client was the cause of the problem, specifically, the anti-virus software.
Removing the SoftGrid SFT file from the anti-virus real-time scanning returned the performance to normal. A very simple, but surprisingly common oversight.
The simple answer is one (1). The sequencer is a single threaded application and will not take advantage of multi-core or multi-socket systems. Sequencer investments are better made in the disk I/O sub-system (see my item on disk performance).
In theory, sequencing on a machine with lots of background processes (for example, indexing, DWM, but not anti-virus) may perform slightly better on a multi-core machine as the sequencer thread will have access to a higher percentage of one of the cores, however, the sequencer is disk I/O intensive and it would be expected that this is where the most performance increase could be gained.
The sequencer, virtual or physical, should have two partitions (or disks), the first, normally C: is for the base build, and the 2nd, 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.
If a virtualised application writes to the event log, will the host machine (and therefore any event log monitoring services) have visibility.
Yes. We don't virtualise the event log in the SystemGuard and therefore any applications that write to it, will be writing to the hosts event log.