Client Log Out

[Damo007]

I have a problem with the view client on my repurposed thin clients which is once a user logs out of their view desktop the physical workstation does not fire back into the view client. It only leaves me with a black screen. How do I make the client start again when a user logs out?

What i'm doing is changing the shell on my workstations to boot in to the client (wswc.exe) . I'm planning on having them not part of the domain. So when a user logs into the client, because thats what it boots up into, they get put straight into their view desktop. I have SSO working I think so they log into the client and log into windows with the same credentials, but they are still being prompted to choose which pool they want. I just want to confirm automatic pool choice is done through GPO by assigning a desktop name to the user?

I've read alot about it on the forums here but I just want to double check I have the right idea. I want the users to have as close an experience to logging into the physical box as they can.

Cheers

[mittim12]

There are command line switches that you can specify when starting the client that will allow automatic pool selection.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[Damo007]

Thanks. Anychance you could point me in a direction to find these switches or break it down a little for me?

Also do you have any ideas why when I log out the view client doesnt fire up into a login screen again and how I can make it do that?

[mittim12]

Here are the options you can use with the client.

c:\Program Files\VMware\VMware View\Client\bin>wswc /?

c:\Program Files\VMware\VMware View\Client\bin>

VMware View Client 4.0.1 build-233023 command line usage:

-desktopName XXX Desktop to autostart

-domainName XXX Domain for server login

-file XXX File with additional command line parameters

-languageId XXX Language ID to use (if available)

-nonInteractive Suppress error message boxes for fully scripted startup

-password XXX Password for server login

-desktopProtocol XXX Attempt to use the specified desktop display protocol

-desktopLayout XXX Specify desktop screen size (e.g. fullscreen, multimonit

or, windowLarge, or windowSmall)

-serverURL XXX URL for the View Connection server

-logInAsCurrentUser XXX Log in as current user

-userName XXX Username for server login

-rollback Rolls back a check out (need -desktopName)

-checkout Check out the desktop for offline use (need -desktopName

)

-checkin Check in the desktop (need -desktopName, must be checked

out)

-staycheckedout Stay checked out after check in (need -desktopName)

-offlineDirectory Local path to check out desktop (need -desktopName)

-? Show this help

Option names are case insensitive.

As far as your client closing maybe you scan script something that looks for the View process and if it's not running starts up the program.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[ChrisKubiak · Accepted solution]

That will happen if you just change the Shell key to point to the actual EXE for the View Client. You need a script that loops launching the client.

Look Here.

Also if you do not want to use command line arguments you can use the View ADM templates to specify many of the arguments as a local GPO. Check the View Admin guide starting at Page 186.

[Damo007]

Thankyou so much Chris, exactly what I was looking for!

I've been doing some testing with it and was wondering how everyone else was using it. Should I have the client computer joined or unjoined to the domain? I was testing some different configurations today and as it is now I have the client computer joined to the domain so when someone logs in it fires them straight into the desktop.

That's not really working for me for a couple of reasons so now im thinking of having the client computer unjoined from the domain and auto logging into a default account on the local PC. Then users are prompted with the view client and get their desktop. Then they log out of the VDI, the client fires up again thanks to that script and no problems they're prompted to login again. What I'm unsure about is if the computer isn't part of the domain can I use GPO's against the users to make it automatically select the pool they're joining with no problems? I remember reading a thread somewhere and the advice was to make sure everything was part of the domain, including the thin desktops (maybe i got that wrong), so I just want to see if my idea will work.

I'm heading back out tommorow to do some more testing but it would be good to have a little prior knowledge of what to expect so I don't waste my time testing configurations that don't work. Really appreciate everyones help, thanks.

[ChrisKubiak]

As far as I'm concerned thin clients on the domain or not is your

choice. You can manage the devices easily if they are on the domain,

but there is some argument that they are more secure off the domain

because in most cases they are auto-log machines and the password is in

clear text in the registry. Also, some would argue that manageability

is not really necessary as you are making the box a "thin-ish" client

and shouldn't need to be managed as long as you built it to your needs

and it runs it should act like an appliance. You could even go so far

as to use something like steady state on the box so that should someone

find a way to bypass the shell replacement anything they do can be fixed

with a reboot.

You can still use GPO to configure whatever settings you wish its just

that you have to use the local policy editor to apply it and not the

domain tool. You can load the VMWare ADM files on the local machine

like you would on the domain to configure whatever settings you wish.

Confidential: This electronic message and all contents contain information

from BayCare Health System which may be privileged, confidential or otherwise

protected from disclosure. The information is intended to be for the addressee

only. If you are not the addressee, any disclosure, copy, distribution or use

of the contents of this message is prohibited. If you have received this

electronic message in error, please notify the sender and destroy the original

message and all copies.

[mholgate]

Here is what I have tested successfully to date:

Using the vbs script and shell replacement previously mentioned works flawlessly for me.

I opted to use a domain user account that is "locked down" significantly with Group Policy.

Even though the password is plainly visable in the registry, the account is so limited that I am not too concerned about it's security.

I have added the necessary View command line switches for it to connect automaticlly to the connection broker and the desktop pool of my choice.

I am currently working on an automated process of simply logging into a workstation with this lockdown account will install the View client and configure it with all the above changes, essentially creating a "thin-ish" client with 1 or 2 reboots.

Mike... VM, Virtually!!

[Damo007]

Nice.

After I made my previous post last night I spent about three hours researching it and found this page which incorporates the previous scripts (except rocket launcher) and adds a bit more to it HERE . I played around with it for about ten hours today and got it working just how i wanted it toon a classroom of machines.

I have the workstations in a workgroup automatically logging into a admin account on the local PC which fires up the view client. When you log into the view client it takes you automatically to your view desktop (no pool selection as I added the group policy templates to the local machine so it selects automatically), then when you logout of the VDI it fires up the client again. Perfect.

Well near perfect.......I dont want my users to see the shade but at the moment I cant figure out how to attach USB devices with hitting connect on the shade. So at the moment I have the shade auto hiding until i can figure that part out. What's the trick with this one?

I'm thinking about pushing out Windows fundamentals via RIS (havnt played with this before so will have to see) with Windows Steady State incorporated and the above scripts. Exactly what i need to repurpose these machines as I want. I thought i'd add it here in case anyone else is looking for a similar solution.

Now to find the answer to my USB problem.............