TechMassey's Posts

Hey Beutlern,            The key is to get a definite answer from VMware. If this was true, it would affect a vast majority of customers. I know full well the difficulty when a different group controls the path forward. I have been on both sides, your going to get the answer you need. As a final option, contact your VMware account rep.

I have never heard of this behavior because ELM by nature is simply linking a view to each inventory with a single pane of glass. Each vCenter still maintains its own inventory. The time a change might occur is if you performed an enhanced vmotion from one vCenter to the other. I recommend going back to VMware to get a second opinion but this time, I'll give you the exact question to help. Please make sure this goes to the Horizon View support team at VMware. To VMware: I have a Horizon View vCenter instance that I want to enable ELM with our other vCenter in order to view both inventories in a single pane of glass. I would also like to occasionally perform enhanced vmotions between the vCenters. SSO authentication will remain with each vCenter and not be shared. To VMware: Will Horizon View be impacted by this change?

It sounds like your trying to work around the fact the memory reservation is in place for the parent VMs. Which, for vGPU is recommended by Nvidia. Here are a couple ways I would tackle this and additional background info. 1. Resource Pools - Your Parent VMs do not need to be in a resource pool for Horizon View to add linked clones to the pool. When creating a VDI Pool, you can choose a specific resource pool you created in the vSphere cluster. Following this strategy, if you create resource pool X and give it a 32GB max mem. Horizon will keep deploying until it hits that maximum. This would work and if your VM count is relativly static would be a long term solution. However, I don't recommend using resource pools because it is far to easy to starve your VMs which impact users. 2. Cluster: DRS and High Availability. This is really the easiest way to meet your needs at a global scale without needing to do a bunch of calculations. Essentially, you rely on HA to reserve resources via admission control. Example scenario is 4 hosts, with 25% reserved. Meaning that HA will stop any VM from powering on if available resources drops below 25%. Leverage DRS to ensure no single host is overloaded. You may need to change the DRS priority depending on balance. I would go #2 but both options are viable.

Exactly, you should have no issues. The actual challenge with implementing Office 365 is non-technical. With Office 365, you need to make sure all users have the correct license level. Else, MS will come knockin since your running on their cloud.

Thanks for the clarification on the random logoff being 100% active. GPO: Did you also run a gpresult under the user and confirm they were not defined? Its odd that the 2008R2 RDS is fine but 2012R2 is not. As a second though, any pattern in the affected users in the last three months from application or OU location? Log: Ive used TS and RDS for a long time, I haven't seen the timer service before. It looks like an internal service to RDS that tracks session time based on the logs.

vMotion of Replicas has been supported for some time. You just need to perform the task in a precise manner. 1. Disable provisioning on the pool(s). 2. Wait, verify all composer tasks stop. 3. Place host with bad HW in maintenance mode. 4. Sit back, watch all the VMs, including the replica get sent off to the other host. In the old 5.x days, this was a major pain due to the protected nature of the replicas.

In the example logoff log, I noticed it states "Initiated logoff on disconnecttimelimit." I suspect the GPO settings for those RDS servers were modified three months ago and now logoff disconnected sessions based on a static timelimit. Check out this GPO settings: Local Computer Policy / Computer Configuration / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session Host / Session Time Limits You  mentioned they are logged off while actively working but I wonder if they are active in the RDSH session when the logoff occurs. I'm quite curious on this issue, let us know!

I have, there was quite a bit of discussion around the license activation piece. The reality is there is not a functionality change with the activation process. It is just pointing to Office 365 instead of your KMS server and checks against the user license vs machine license. Which means, as long as you are storing a copy of their mail profile AND you have Office GPO settings in place to suppress the new mailbox setup. You won't have any wide spread issues switching your installation of Office to Office 365.

Based on the description, I am guessing you have the pool configured to store the replica in a separate datastore. That is the cause of these types of issues and it seems to affect customers randomly. The issue should go away if you choose to not separate the replica. That is not the ideal solution but it lets you function while you continue to work on it as time permits.

I agree as well. Likely the OP has multiple datastores in which case a datastore cluster with storage IO like sjesse mentioned would work. One item though, this is an unusual request. Typically, VDI doesn't need to have this limit in place as dedicated storage is in place. This could be an over subscription issue on the storage I/O or perhaps a specific app generating the I/O. What is the behavior you are seeing that requires limiting the I/O?

There could be a number of different causes for this issue. In a case like this, a dive into the logs and system events is needed. Do you have a support contract with VMWare? If so, I would create a support ticket to look into this further.

It sounds like it does work in one direction correct? That indicates the policies are working but a configuration issue may exist. The best course is to break out the components. Since you mentioned a standard win 7 VDI desktop is working bi-directional with the clipboard. I would login to the RDSH host directly with an identical test user. Test the clipboard and also generate via CMD a GPResult Report: GPResult /H %userprofile%\gpresults.htm.

There are too many variables here. If I had to guess, the 2012 server and the Windows 7 VM are not on the same subnet. The second guess is DHCP helper is not configured on the subnets. My recommendation, is placing a standard VM on the same subnet as the 2012 VM. If no DHCP is received, then contact Microsoft support for further assistance.

In situations like this, I highly recommend removing potential sources such as UEM. Have a service account that is not part of your UEM architecture. Log into the VM either through console or Horizon View HTML to test. If it works, then go back to review the UEM logs and application behavior. I have been using Horizon View for over 5 years and have a dozen service accounts for various purposes. The ROI with these accounts cannot be easily calculated.

That is exactly our situation and PrinterLogic was a game changer. Help Desk in particular is ecstatic at the easy level of provisioning when users move to new locations. I'm particularly impressed with the driver support, especially Mac. It all works very well, in fact in the last 2 years I'm not aware of any specific issue. The only other vendor I have that good is Nimble Storage.

Typically that indicates a failure in the customization process. I know you mentioned it successfully joining to the domain but I would review your customization settings. Double check the service account, destination OU, quick prep or sysprep options. If you could, screen shot your customization tab on the pool. You can blackout the proprietary info.

Good to hear that DHCP is back in order. I'm sure why the NTP lookups are happening rapidly. Could be a symptom. Back to your issue, the servers are pingable while windows explorer does not work. Are they pingable by DNS and IP? That part is critical, because if they are this is likely local to the OS vs being a VMware issue.

Thanks for the detailed info! Can you confirm if the logs show the incoming connection at the security server or agent level? Is there any evidence any component at all sees the incoming connection in the logs?