I currently have a small VDI pilot underway and we decided after reading all the rave reviews of VDI blaster on this forum to go with it. We are repurposing a few of our kiosk machines here as thin clients to connect to our VMware view desktops. The problem I am encountering is that the VMware view client in VDI Blaster keeps incorrectly setting the resolution of the desktop. I have the client connect and select full screen as the resolution type, but the desktop resolution is either to small or too big and does not fit the full screen. I am running vmware view 4.5 (PCoIP) and VDI Blaster DeTOS 7. I have not had this problem using both the windows VMware view client or the VMware view linux client (built for HP thin clients, compiled on Ubuntu) so I know it's not anything in view which is causing this behavior. Has anyone else encountered this problem and have a solution? I've also engaged Devon IT support, so if I hear something from them I'll post it here. Thanks in advance
You have to set it in virtual center. You can either set the master clone res, in which case the clone will take that, or you can set it on the clone itself, which is what I've done for my pilot. I am gonna see what Devon IT say, because this is only a workaround. In production, it's just not at all practical.
Hi, I've had a similar issue with VDI blaster. It seems that the DeTOS client likes to take the native resolution of the VM (or so it seems in my case). So as a workaround, after adding enough video memory (35MB) on the VM to support the repurposed client screen resolution (1280x1024), I set the resolution on the VM to 1280x1024. VDI blaster now runs in the correct resolution. For my pilot this is fine, but in production, when people move about and log onto different workstations with different screen sizes, I can see it causing issues.
You really want the VDI blaster to work like other zero clients and resize themselves to full screen accordingly. I'd like to hear what the response is from Devon IT.....
I've added video ram to the master and recomposed the pool, but the clones don't retain an identical setting to the master. My clones right now have about 17.8mb while my master has 32mb. should 17.8 be sufficient? Can anyone explain why the settings aren't identical?
Take a look at page 32 of this: http://www.vmware.com/pdf/view45_architecture_planning.pdf it will give you the amount of video RAM needed depending on the resolution you want.
Your linked clones should be identical to the master??
The View connection brokers should control the amount of memory assigned during sessions based on the resolution and number of monitors set on the pool.
thin and zero clients resize the screen accordingly as you'd expect, but for some reason, repurposed fat client workstations wont (e.g. VDI blaster and 2X CCOS) they seem to take the native resolution of the clone. No problem for a pilot but when users start moving about in a production environment, this wont be practical.
How can I set the native resolution of the clone? Does it just take the settings from the master? I didn't see anywhere through the view admin interface to set this (I can set the max resolution, but not the default).
You have to set it in virtual center. You can either set the master clone res, in which case the clone will take that, or you can set it on the clone itself, which is what I've done for my pilot. I am gonna see what Devon IT say, because this is only a workaround. In production, it's just not at all practical.
I've been working with Devon IT for a couple days now, they thought the issue might have been that the view client included with DeTOS 7.1 is view 4.0, so they gave me access to the beta of the new version, which has view client 4.5. However, I just installed it and I'm still having the same issue. The curious part is the very first time I connect, it works, and every other time afterwards it doesn't.
I set the resolution on the master clone as you suggested and it works. Like you said, this is fine in our pilot (3 machines) but if we go to production and have multiple machines with different monitor types and different resolutions in the same pool, this will not be good.
I used several different things to get this to work for me in my environment. First I have a script figures out where the computer is (different locations have different size monitors). Then, I have a script that resizes the screen resolution.
Here is the bat file I created:
@ECHO OFF
ECHO Change Resolution...
REM This part turns the station name into a variable
REM VDI Blaster uses the MAC address as the station name
REM Kiosks
IF (%ViewClient_Machine_Name%) EQU (Kiosk-1) GOTO KIOSK
IF (%ViewClient_Machine_Name%) EQU (00-09-74-26-08-CB) GOTO KIOSK
REM The top line is for future use and the bottom line is for VDI Blaster
IF (%ViewClient_Machine_Name%) EQU (Kiosk-2) GOTO KIOSK
IF (%ViewClient_Machine_Name%) EQU (00-0C-DB-64-93-3D) GOTO KIOSK
IF (%ViewClient_Machine_Name%) EQU (Kiosk-3) GOTO KIOSK
IF (%ViewClient_Machine_Name%) EQU (00-13-3F-46-90-96) GOTO KIOSK
IF (%ViewClient_Machine_Name%) EQU (Kiosk-4) GOTO KIOSK
IF (%ViewClient_Machine_Name%) EQU (00-09-74-DC-AF-45) GOTO KIOSK
IF (%ViewClient_Machine_Name%) EQU (Kiosk-5) GOTO KIOSK
IF (%ViewClient_Machine_Name%) EQU (00-0C-DB-64-9B-8A) GOTO KIOSK
REM Library
IF (%ViewClient_Machine_Name%) EQU (LIB-1) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (00-14-72-8F-CB-91) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (LIB-2) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (00-14-72-8F-E0-4B) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (LIB-3) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (00-14-72-76-81-11) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (LIB-4) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (00-14-72-8F-CB-72) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (LIB-5) GOTO LIB
IF (%ViewClient_Machine_Name%) EQU (00-14-72-8F-E1-C7) GOTO LIB
ECHO Other...
REM This section catches all of the stations that don't fit the scripting above
REM The next line sets the default printer
start /W RUNDLL32 PRINTUI.DLL,PrintUIEntry /y /n PDFCreator
EXIT
:KIOSK
ECHO Kiosk Default Printer...
REM Setting the Default Printer
start /W RUNDLL32 PRINTUI.DLL,PrintUIEntry /y /n \\Kiosk-HP1320.Students
ECHO Change Screen Resolution...
REM I found a program that will resize the screen with the script below
C:\Scripts\Reschange\reschange.exe -width=1024 -height=768
EXIT
:305
ECHO 305 Default Printer...
REM Setting the default printer
start /W RUNDLL32 PRINTUI.DLL,PrintUIEntry /y /n \\Library-HP3005.Students
ECHO Change Screeh Resolution...
C:\Scripts\Reschange\reschange.exe -width=1280 -height=1024
EXIT
That is my work around. It was really annoying to collect all of the MAC addresses but it works great now that I am done.
-trb48
Just to add to this - I've also got the new Blaster beta version (7.0.3 10.10.07) with the View 4.5 client and resizing now works as expected.
If you still have issues, make sure that you set up a new Blaster client connection with the beta software, set to auto-detect the resolution then clone this back to the thin-manage server, then create a new profile before pushing this out to the new clients.
Cheers