Problem: Was trying to upload a custom wordpress theme from themeforest.net and during the upload the theme uploader was crashing out prompting with ‘Are you sure you wan to do this? Please try again.’
Solution: Easy one really, ensure you are uploading the WordPress theme only and no other (the zip file will typically be the name of the theme.
The zip file will typically be:
themename.zip > themename.themeversion > with css, img, inc, js languages and plugins folders and a bunch of php files.
Security Log > Audit Failure Event ID 4625
An account failed to log on.
Security ID: NETWORK SERVICE
Account Name: SERVER$
Account Domain: DOMAIN
Logon ID: 0x3e4
Logon Type: 8
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: jamesscanlon
Account Domain: DOMAIN
Failure Reason: Unknown user name or bad password.
Sub Status: 0xc000006a
Caller Process ID: 0xa20
Caller Process Name: C:Program FilesCitrixReceiver StoreFrontServicesDefaultDomainServicesCitrix.DeliveryServices.ServiceHosting.WindowsServiceHost.exe
Our C: drive on a test PVS image (Private mode acccess) was nearly full
We extended the vDisk following this process
- Open Cmd Prompt
- Select vDisk file=”Path to your PVS vDisk”
- List vDisk
- expand vDisk maximum=xxxxx (in Mb) (61440 for 60GB etc)
- attach vDisk
- list Disk
- list volume
- Select volume x
- List volume
- detach vDisk
After detattching and booting the Test PVS Server windows wouldn’t boot with a System volume couldnt be accessed
Repeat steps 3,6 and 12 to reattach the disk and deattach the vdisk cleanly then boot the VM.
Situation: After an upgrade of our VPX devices to FW 10.1.121.10 intermittent authentication issues appeared for the access gateway users. They would simply fail the LDAP bind, yet all monitors would be green with all services up. Our radius and LDAP authentication point internally to a LB VIP on the Netscaler first before connecting to the individual servers.
Solution: At this stage Citrix support are investigating the issue, they have recognised it as a bug and their workaround solution was to bypass the netscaler load balancer for LDAPS going direct to a specific server, or to downgrade to 10.1.120.13. The downgrade was not a solution for us as we already had issues with the previous version with the VPX network and LACP negotiation.
Once we removed the internal LDAPS load balancer the Netscalers started authenticating immediately.
We then added another policy for a secondary authentication policy and server so we did not introduce a single point of failure.