On the Windows HiEd list serve, the topic of how best to include machines that are NOT part of your AD domain environment within your SoftGrid deployment came up.  In short, SoftGrid relies 100% on Active Directory to act as the Authentication and Authorization source when making decisions on who (ie, what AD groups/users) to stream virtual applications.  Thus, without AD deployed, you don't get very far with SoftGrid...

In many HED and even K12 environments this can be a showstopper as there are several scenarios where desktops may not be part of an AD environment or trusted AD environment for a laundry list of reasons - both political and technical.  However, you CAN still use SoftGrid to stream applications to these 'untrusted' desktops - you still need AD somewhere for SoftGrid to reside as this current version must have AD to operate, however, you do not need to have all desktops participating in this AD as member workstations. 

Basically, the following SoftGrid knowledgebase article details how to allow workgroup desktops access to your SoftGrid system.  Basically, you need to instruct the owner or user of that workgroup machine to use a cached domain username and password when communicating with your SoftGrid server or servers that has the appropriate access to the desired virtual applications.  But the problem here is that you have to rely on that user to walk through the steps to accomplish this and they may not be savvy enough to do this.  So one idea might be to script during the install of the SoftGrid client, create a web page, HTA, or whatever that utilizes the cmdkey.exe command line to inject these domain credentials on behalf of the user.  CMDKEY.EXE is in the path (System32 directory) on Windows Server 2003 and Vista desktops but NOT XP desktops by default, however CMDKEY.EXE executes just fine on an XP machine.