In a previous post, I mentioned the DoD’s Lightweight Portable Security bootable Linux as applicable for some situations. The current LPS Public 1.3.5 ISOs come in two configurations, the basic and deluxe.
The deluxe version is a 401MB bootable ISO. It includes clients for Citrix, VMware View, and MS Remote Desktop. Also includes OpenOffice and Firefox.
As a bootable ISO, it also works within a virtual machine. This makes for a handy way to use the bootable ISO’s included clients for Telework without giving up full use of your physical computer during the remote session.
For government organizations which need additional customizations (pre-loading target URLs, additional client apps/versions, etc), customization is available at no cost to DoD organizations. Other non-DoD Federal organizations, the customization charge is $10K with an annual $2K maintenance fee. The Air Force organization providing this is looking into means to offer customized versions for State and Local govt organizations as well. The public versions are free to everyone.
Additional documentation is available on their website.
For someone just beginning the process of creating a bootable LiveCD for their own organizational needs, this provides a nice clean example to start from.
One of the VMview forum threads mentioned some ways to map a drive from a Virtual Machine back to the physical machine running the VMview client.
After looking at the suggested scripting, I decided to see if I could do it manually. Within the remote virtual desktop, use these steps:
- Windows File Explorer.
- Menu | Tools | Map Drive.
- Select a drive letter.
- Enter a source –> example… “ \\xxx.xxx.xxx.xxx\c$ “.
- When prompted, enter login credentials.
Replace xxx.xxx.xxx.xxx with the IP address of your physical client machine.
The steps I used to test how well this would work and verify what protocol the file transfer would use included:
- map the drive from the VIEW VM back to my laptop.
- Launch Wireshark on my laptop and filter traffic on “net xxx.xxx.xxx.xxx/xx”.
- Moved about 340MB of files thru the View Client session.
- Analyzed the protocol/traffic results in the Wireshark capture.
- RESULT –> observed ~340MB of traffic over UDP 50002 (PCoIP).
The forum thread mentioned an area of the VM’s registry where a script can look for the user’s client IP address.
Quite a bit of session information in here, including:
- LOGONSERVER \\SERVERNAME
- USERDNSDOMAIN YOUR.DOMAIN
- ViewClient_Broker_DNS_Name ViewConnectionManager.YOUR.DOMAIN
- ViewClient_Broker_URL http://ViewConnectionManager IP:80
- ViewClient_Broker_Remote_IP_Address “your client machine’s IP Address”
- ViewClient_IP_Address “your client machine’s IP Address”
- ViewClient_LoggedOn_Domainname “your client machine’s DOMAIN”
- ViewClient_LoggedOn_Username “your client machine’s HOSTNAME”
So it certainly appears we can build scripts/policies for the View sessions which make decisions based on which domain or network the user’s physical client comes from. Or, in the event we deploy multiple connection brokers/URLs, we could base policy/script decisions on how they connect to the View environment (which URL, which security level, which protocol, etc.,)
A customer with Windows 7 VMs in their VMview environment is seeing a lot of disk space consumed by hypernate files. The VMview Manager, vSphere, and ESX can manage the power, memory, and disk images for each VM. As a result, it is redundant and even counter-productive to allow the Windows OS perform power management for themselves when running as a Virtual Machine.
- Click Start, and then type cmd in the Start Search box.
- In the search results list, right-click Command Prompt, and then click Run as Administrator.
- When you are prompted by User Account Control, click Continue.
- At the command prompt, type powercfg.exe /hibernate off, and then press ENTER.
- Type exit and then press ENTER to close the Command Prompt window.
Eliminated 3.1GB of disk usage from each Windows 7 VM in the customer’s VMview environment. This setting achieved a savings of approximately 7TB of Enterprise SAN.