Ryan Goldstein
-
Posts
16 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Ryan Goldstein
-
-
yea its always there one where you think "I dont have to test that one, no way THAT policy is causing this issue". It's always that policy.
-
You have a policy in your windows 10 OU that is breaking registration. Test the policys one by one.
-
How are the user profiles setup? Roaming, Redirected, 3rd party?
In Director it will tell you how long each part of the logon process is taking.
-
It has never been that way. You can either have a non-persistent catalog or a persistent one.
If you have a persistent desktops the only way to refresh the desktops is to delete them and create new ones. This can automated.
If you have non-persistent they refresh at every reboot, there is a distinction between DDC reboot and vmware reboot.
-
What port is storefront using for xml communication to DDC. Unless you installed cert on DDC make sure it's set to 80
-
HKLM\Software\Citrix\DesktopServer\MaxFailedRegistrationsAllowed
Value = -1 (REG_DWORD)
If -1 is set, DDC will not put the VD in maintenance mode, regardless if it has registered successfully or not
Default is 2 if not set
HKLM\Software\Citrix\DesktopServer\MaxRegistrationDelayMin
Value = 20 (REG_DWORD)
Default is 20 if key not present
http://discussions.citrix.com/topic/296460-maintenance-mode-being-automatically-enabled/
-
1
-
-
Also if you schedule for 30 min after boot, citrix is going to think there is an issue and put the desktop into maintenence mode.
-
hahaha that's a good problem to have i guess.
Set the Citrix Desktop service to delayed start on your Master Image.
Set the Desktop service to manual and start the service with a script after a set amount of time.
With 550 desktops you would have about 55 desktops in your ready pool by default, as far as i know its a random what desktop a user gets put on. That should be big enough where a user should not regularly get a newly registered desktop, so i'm skeptical that is your issue, but GL to you.
-
1 policy add on controllers.
1 registry change on virtual image.
1 registry change on local endpoint.
Do the reg keys first because if you examine the key you will understand how the policy works.
-
Hubs are restricted by default. You will have to make an explicit rule to allow them in policy, and also edit the local reg key.
HKEY\LocalMachine\wow64\citrix\portICA\GenericUSB - Device Rules
WOW64 or not depending on your OS, this is at the endpoint where receiver is installed as well as on the Virtual Desktop.
Good luck probably not supported.
-
Ryan, we do have server component installed but fails to redirect.
You also have the topez "sigsock" endpoint client installed on LOCAL windows OS that is used to launch the session.
Topez or whatever company is supplying the sig pads are usually helpful in troubleshooting.
I would suggest taking a step back and setting it up clean in a lab or dedicated instance, i know with topez the installation order is very important and signatures will not work if items are not installed in the correct order.
-
1
-
-
I have not seen this feature since 6.5. Sorry.
-
Also Topaz releases SigSock for redirecting the signature data through the ICA session. This gets installed on the local desktop needs to be windows OS at the endpoint. There is a also a server component that goes on your master image.
ERROR Address already in use
in Core ADC use cases
Posted
go under netork > IP addresses and remove the IP from the orginal netscaler, removing VIP does not remove IP.
Maybe even on new netscaler its their by mistake