sgravel's Posts

sgravel's Posts

Any word on whether this issue was resolved? As I understand it, connecting via PocketCloud using two-factor with RSA works if the RSA and AD usernames are the same, but not if they are different. W... See more...
Any word on whether this issue was resolved? As I understand it, connecting via PocketCloud using two-factor with RSA works if the RSA and AD usernames are the same, but not if they are different. We would like not to have the names match...
Thanks Lana. When you say "fixed", do you mean that if a password is not present in the profile, the client will prompt the user upon connection, but that the capability to store a password in ... See more...
Thanks Lana. When you say "fixed", do you mean that if a password is not present in the profile, the client will prompt the user upon connection, but that the capability to store a password in the profile for a View connection will still be present? I recognize that we're only one of many competing viewpoints you need to consider, but for us that would still be a huge negative. Ideally, given that View is predominately, if not exclusively a business oriented solution, it would be great if the password field was omitted from the View connection profile alltogether. I cannot think of another IT person who would want that information to be stored on a mobile device. Thanks again!
VMware View connection item REQUIRES you to save your password? We're evaluating whether PocketCloud is an acceptable client for remote access to our VMware View 4.6 infrasrtucture, and I am thi... See more...
VMware View connection item REQUIRES you to save your password? We're evaluating whether PocketCloud is an acceptable client for remote access to our VMware View 4.6 infrasrtucture, and I am thinking, mostly for one reason, that it is not. Maybe somebody can point me in the direction of what I am missing. Coming from the IT side, I have exactly zero interest in users saving their passwords inside profiles on their devices. At that point, all that is standing between us and a security breach (unless we do 2-factor) is the lock PIN on the device itself. That's a shaky thing to rely on. I am finding that if I don't specify my password in the View connection profile in PocketCloud, I get an error that "Connection data is missing", and I have to edit the profile, save my password in it, and then connect again. Then, of course, it is still in there until I re-edit the profile and remove it. I don't see users doing that reliably. Anyway, although it is less flexible, the tech preview of VMware's View app for Android has one thing going for it - it doesn't even offer to save your password anywhere. In a business environment, that's a real plus. Is there anything that I can change to make it refuse to save passwords, and to prompt every time instead? Thanks
Thanks Roman,  I will give that a try.
I was told by support that there would be an enhancement forthcoming to address this issue before 4/24/11, but my efforts to contact Quest directly to get an update on this have met with no response.... See more...
I was told by support that there would be an enhancement forthcoming to address this issue before 4/24/11, but my efforts to contact Quest directly to get an update on this have met with no response.  Meanwhile, this continues to be a daily nightmare for our support team and our users.  I recognize that 4/24 is still a month away, but trying to be optimistic, they did say "before" 4/24.  Even a couple weeks at this point might mean a difference in our course of action regarding vWorkspace. Quest - can you respond as to the status of this issue? Thanks
I'll buy that.  How about as a second step after retrieving the list of IP addresses from WMI, the Data Collector does a quick check and chooses the IP address from which it can actually connect to ... See more...
I'll buy that.  How about as a second step after retrieving the list of IP addresses from WMI, the Data Collector does a quick check and chooses the IP address from which it can actually connect to the configured broker?  If I can "ping -S" from a specific address on my machine, surely the Data Collector could perform some similar function.  If not, maybe it could look at the routing table on the client machine and pick a better choice than the first one on the list?
I'm seeing this on one of our VDI machines now as well.  VDI machine is running PNTools version 7.2, and had 7.1 on there at one time.  We're having an issue with Universal Printing where sometimes j... See more...
I'm seeing this on one of our VDI machines now as well.  VDI machine is running PNTools version 7.2, and had 7.1 on there at one time.  We're having an issue with Universal Printing where sometimes jobs fail to print to the client printer in their entirety.  The VDI machine becomes completely unresponsive as a result.  I had to power it off and back on instead of restarting it (no other choice), and when I later went to turn on diagnostic logging in the Quest UP client (or do anything else on the VDI machine that required elevation), consent.exe faults and I get the pop-up about extended attributes.  Anybody find another way aside from disabling the UAC?  That's not an option for us.  I am thinking about uninstalling and re-installing PNTools later, but not sure that will help.
I realize that RHEL 6 is not listed under system requirements, and 5.5 is, but I figured I would have a go at getting the connector to work under 64 bit RHEL 6. Following the install process, I cr... See more...
I realize that RHEL 6 is not listed under system requirements, and 5.5 is, but I figured I would have a go at getting the connector to work under 64 bit RHEL 6. Following the install process, I created a sym link to my kernel source, and was able to run the pre-req checker successfully.  Could not find a suitable speex, so that is the one thing I am missing.  According to the script, this should just mean that microphone redirection does not work.  All other items present and accounted for. I installed using the wizard.  When I tried to launch qrdesktop from terminal, it told me it could not open the shared library libscrypto.so.6.  I had a newer version in /usr/lib, so I sym linked to that, and resolved that error.  Now, I get a simliar error about something else: qrdesktop: error while loading shared libraries: libao.so.2: cannot open shared object file: No such file or directory A newer libao lives in /usr/lib64, but sym linking there does not affect the error, and creating a sym link in the /usr/lib folder to the newer libao in /usr/lib64 rightly complains that the architecture is wrong. As I said, I passed all the pre-req's in the script.  Any idea how I might get this going?  Is the linux connector going to get an upgrade given that the core product is on 7.2 now? Thanks, Steve
Hi again, I appreciate the workaround that Andrew suggested, even though it didn't pan out, but I've gotta say - I expected someone to throw out some more information as to the roadmap on this iss... See more...
Hi again, I appreciate the workaround that Andrew suggested, even though it didn't pan out, but I've gotta say - I expected someone to throw out some more information as to the roadmap on this issue.  It's been a problem for vWorkspace for a while from what I understand, and with my case as an example, I would think you would run up against this fairly frequently in the business world.  To say that "you just can't do that" (as the KB article does) is not an acceptable answer. In the real world, clients and business partners have very specific allowable modes of access for their outside vendors.  I've gotta believe that client based SSL VPN is fairly common.  I'd love to put a device on our network that can terminate the end of the tunnel somewhere other than on the client, but given our client's policy, that will not be possible.  That means that by Quest's definition, the machines are "multi-homed". If Quest is about to do something about this, and just has not responded, please do, either here or in my support ticket.  If not, I have no idea why a problem that potentially has a simple solution has been allowed to linger for so long.  There is a lot of information delivered by WMI along with an IP address, just poking around technet.  Seems like there would be clues in there as to what the right adapter to choose would be.  I am assuming you are looking here: Win32_NetworkAdapterConfiguration Class http://msdn.microsoft.com/en-us/library/aa394217(v=vs.85).aspx Please let me know what I should expect from Quest in the way of assistance with this, and when.  If there is nothing that can be done soon, I need to cut my losses with this product and find another solution. Thanks, Steve
Just looking at the KB article, and wondering (emphasis added): Multiple IPs/NIC configurations are not supported. Quest Data Collector service retrieves IP through WMI and refers to the first ava... See more...
Just looking at the KB article, and wondering (emphasis added): Multiple IPs/NIC configurations are not supported. Quest Data Collector service retrieves IP through WMI and refers to the first available one. Since Quest Data Collector does not have control of WMI, it cannot predict which IP will be used and reported to the Connection Broker. The way I read that, WMI returns several IP addresses to the Data Collector's query, i.e. 10.10.1.24, 10.120.149.12, 192.168.1.43.  Then, the DC refers to "the first available one".  Would it not be better, in almost every case, for the DC to parse the list and choose the one on the same subnet as the broker?  If there is a scenario I am not considering, could this not at least be made an option? It sounds like WMI is returning choices, and DC is essentially choosing one at random.  From my experience, being the first IP address on the list does not mean anything.  Being an IP address on the same subnet as the broker means everything.  If WMI is returning a list, and I can pick out the right one, DC should be able to as well, yes?
Hi Mark, Yes - split tunneling is allowed.
Hi Andrew, Just tried your suggestion, but I ended up with different results. I chose a user who has this issue, and whose entry in the vWorkspace console had the IP of the VPN adapter listed. ... See more...
Hi Andrew, Just tried your suggestion, but I ended up with different results. I chose a user who has this issue, and whose entry in the vWorkspace console had the IP of the VPN adapter listed.  I looked at the bindings, and sure enough, the VPN adapter was listed first.  I clicked the LAN adapter to the top, and within a few seconds, the vWorkspace console was reporting the correct IP. I had the user disconnect the session and then reconnect to it.  All good. Then, I closed the VPN session and re-established it.  This caused the IP reported in the vWorkspace console to be that of the VPN adapter.  I opened the list of bindings again, and the LAN adapter was still at the top, with the VPN adapter beneath it.  I opened the listing completely from scratch (Control Panel>Network and Sharing Center, etc.), so I am pretty sure I was not looking at a stale binding list. This is all consistent with what support told me.  They stated that they had experimented with binding order, but it did not produce a permanent improvement.  Windows remembers and respects the binding order you specify, even if you have adapters that are dynamically added and removed from the system, it would seem.  Unfortunately, the WMI query you are doing to get the IP address for the VDI desktop does not appear to get an IP from the first adapter in the binding list, at least every time. Thanks for the suggestion, though.
I have a ticket open on this with support, and I am sure that's the best way to get up to the minute information on this, but I am posting here to see how other users who have this issue have worked ... See more...
I have a ticket open on this with support, and I am sure that's the best way to get up to the minute information on this, but I am posting here to see how other users who have this issue have worked around it, if it's possible, and also to make my disappointment clear to the Quest folks who watch these forums. I have the issue outlined in Quest KB article 68168.  Our VDI desktops are not multi-homed in the sense that they have physical NICs, but they do have an SSL VPN client that has its own IP, which is used to connect to one of our client's intranets.  This has resulted in all manner of connectivity issues.  Users who get disconnected cannot reconnect to their sessions if they are using the VPN client, because the broker is looking to connected the client to an IP it cannot see (the VPN adapter).  The broker is also unable to manage the VDI machines.  It's a nightmare.  I have partners in our firm who are using this solution, and are wondering why I chose it. Support tells me they've been aware of the problem for a while now, but that there is still no resolution or even a workaround.  I'd be the guy with a handful of licenses who probably does not carry much weight, but we will need to go elsewhere if there is no solution to this issue in the very near term. Frankly, I am a little stunned that you don't take this into account in the world of B2B interaction... I'd be thrilled if there was at least a way to force the adapter used for vWorkspace with a registry hack or something, at least for now. Help!!
Thanks for the suggestion, Mark.  I'm just untrusting by nature.  I have nightmares where they save the password despite our written policy, then one of their kids gets done watching a Netflix movie ... See more...
Thanks for the suggestion, Mark.  I'm just untrusting by nature.  I have nightmares where they save the password despite our written policy, then one of their kids gets done watching a Netflix movie on the iPad, and says "Oooh...  what's this vWorkspace app?"  We need a way to lock it down, and I guess that's going to need to be multi-factor auth.
Thanks.  Will have to investigate the VPN client and see if that affords us any security options.  With the vWorkspace iPad connector willing to save credentials, and the iPad itself being very porta... See more...
Thanks.  Will have to investigate the VPN client and see if that affords us any security options.  With the vWorkspace iPad connector willing to save credentials, and the iPad itself being very portable and not very secure (no centrally enforcable security policies that I know of), I don't know how we can let our employees use this.
OK, so by filling in the broker name and broker tcp port with those of the secure-it gateway, I was able to get a list of managed apps, but they don't connect when I tap them.  "Could not establish a... See more...
OK, so by filling in the broker name and broker tcp port with those of the secure-it gateway, I was able to get a list of managed apps, but they don't connect when I tap them.  "Could not establish a connection to the server".   A little closer...
I must be doing something boneheaded... Trying to connect from the iPad through our Secure-IT gateway to the broker.  I've set up the farm and location just like they would be in AppPortal for an ... See more...
I must be doing something boneheaded... Trying to connect from the iPad through our Secure-IT gateway to the broker.  I've set up the farm and location just like they would be in AppPortal for an externally located user, but when I attempt a connection, I receive the error:   "There are currently no logon servers available to service the logon request" The iPad has Internet connectivity.  I know it has nothing to do with the app, but I can even visit the Web-IT page in Safari from the device.  Point is, I know it can resolve the gateway name, likes the certificate, etc. PC based users are getting in via AppPortal without issue. My location in the config is set to use https. I've tried the FQDN of the broker and also the IP address.  Neither are resolvable / accessible from the Internet, but I am under the impression that the secure gateway settings further down the page will set up a secure tunnel that will take care of that issue.  Broker tcp port is correct as 8080. I have NAT off, and RDP over SSL on - again, just like they would be in our functional AppPortal config.  Our secure gateway FQDN is able to be resolved on the Internet, so that's what I entered in the secure gateway field along with the port, as in "portal.ourdomain.com:4443".  Our Secure-IT gateway is handling both broker and web traffic, hence the non-standard port. Any ideas? Thanks, Steve
One interesting pitfall I remember encountering is that if the tools install on the host detects a native remote multi-monitor capable OS like Win7, that functionality is used instead of vWorkspace's... See more...
One interesting pitfall I remember encountering is that if the tools install on the host detects a native remote multi-monitor capable OS like Win7, that functionality is used instead of vWorkspace's MM.  Unfortunately, some editions of Win7 that you might encounter in a small business (Pro for example) don't support MM when they are set up as a remote desktop host.  You need your host to be Win7 Enterprise or Ultimate for that.  Fortunately most business are entitled to Enterprise through a site licensing agreement or SA, but it's just weird that you can get MM when connecting to an XP Pro host, but not a 7 Pro host.  Maybe Quest could make the MM capability check look a level deeper and evaluate the edition of the OS on the host - it's 7, but is it Pro, Enterprise or Ultimate - and act accordingly.
Hi Jon, We're running our small pilot on beta code at the suggestion of one of the Quest reps (before MR1 came out).  We have no GA environment to test on, so I can't open a ticket.  We'll just wa... See more...
Hi Jon, We're running our small pilot on beta code at the suggestion of one of the Quest reps (before MR1 came out).  We have no GA environment to test on, so I can't open a ticket.  We'll just wait to rebuild on 7.2 GA when that comes, and open a ticket if the problems persist. Thanks, Steve
We're playing with 7.2b1, but I think this also happened when we were on 7.1, so I will post this in this forum instead of the beta forum. Weird behavior number 1:  Sometimes when I first unlock t... See more...
We're playing with 7.2b1, but I think this also happened when we were on 7.1, so I will post this in this forum instead of the beta forum. Weird behavior number 1:  Sometimes when I first unlock the password protected screen saver on my existing session / VM, Outlook behaves as if I have the CTRL key pressed.  Every message I select is selected in addition to the currently selected messages.  Pressing ESC reverts things back to normal.  This may happen in other apps, but it never occurred to me to check until just now.  We don't see this on non-vWorkspace machines (physical, stand alone RDS, etc.) Weird behavior number 2:  Frequently, if I minimize my vWorkspace desktop session, and work "locally", if I open a local browser, the session is maximized again.  After minimizing the session, I see that the browser did in fact open too, but it's annoying that the session maximizes as well.  Both client and host are Windows 7. Thanks for any insight! Steve