Saturday, November 29, 2014

Lync Server 2013’s Deploy Monitoring Reports wizard throws the error: Cannot grant ReportsReadOnly Role to user “domain\accountName”. For details, see the following error message: Exception calling “Create” with “0” argument(s): “Create failed for Login ‘domain\accountname’. “

Problem

You’re in the process of deploying Monitoring Reports for Lync Server 2013:

image

… and proceed through the deployment but receive the following error:

Cannot grant ReportsReadOnly Role to user “domain\accountName”. For details, see the following error message:

Exception calling “Create” with “0” argument(s): “Create failed for Login ‘domain\accountname’. “

image

Solution

When entering the name for the User name (domain\user name): field, ensure that you use all capitals for the domain name as such:

CONTOSO\<username>

… because it needs to conform with the SQL Server standard as shown here:

image

Using small letters such as:

contoso\<username> will throw the error shown above.

image

Once this format is used, the deployment should complete without any errors:

image

Tuesday, November 25, 2014

Securing a Citrix NetScaler IP (NSIP) GUI Access with an SSL Certificate

I’ve recently been asked how to configure the Citrix NetScaler administration GUI console with a secure certificate so that the login credentials would not be passed in clear text and while I’ve done this numerous times without giving the process much thought, I never wrote a blog post about it.  Doing a quick search on the internet did not appear to return a Citrix KB that clearly showed up to do it so this post serves to demonstrate the process.

Before I begin, the closest Citrix KB that resembles this task is the following:

How to Enable Secure Access to NetScaler GUI Using the SNIP Address of the Appliance
http://support.citrix.com/article/ctx111531

The article in the link above demonstrates how to configure a SNIP (Subnet IP) that allows NetScaler administration GUI console access and while there are many benefits in doing so, if configuring an additional SNIP for GUI access is not desired, we can achieve the same results with the NSIP as well.

First off, the NetScaler NSIP is actually configured with the default ns-server-certificate certificate by default and is indeed listening on port 443 (https) as shown here:

NetScaler –> Traffic Management –> SSL –> SSL Certificates

image

The problem here is that the key size is only 512-bit and browsers today would refuse to connect to a website that uses a certificate that is 1024-bit or less:

image

This is why you receive the following webpage if you try to use https://<netScalerIPorName> to access the GUI administration console:

There is a problem with this website’s security certificate.

The security certificate presented by this website is not secure.

Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

We recommend that you close this webpage and do not continue to this website.

Click here to close this webpage.

More information

image

If the default certificate was at least 1024-bit then you would have gotten a choice to proceed but because the bit level does not meet the minimum requirements of the browser, you are left with only the option to close the webpage and terminate the session.

Step #1 – Request and Install a valid SSL Certificate

A valid certificate must be installed prior to enabling SSL access to the NSIP GUI and since I’ve written a blog post in the past about this, I’ll simply refer to it rather than outlining the steps again:

Generating CSR and installing certificate on NetScaler VPX 1000
http://terenceluk.blogspot.com/2012/10/generating-csr-and-installing.html

Step #2 – Assigning a SSL Certificate to the NSIP IP

The KB article I listed above demonstrates the process of configuring the SNIP via CLI but here I will demonstrate how to configure it via the GUI.  Begin by logging into the NetScaler’s GUI console and navigate to:

NetScaler –> Traffic Management –> Load Balancing – Services –> Internal Services

image

The IP address that represents the NSIP of the NetScaler are as follows:

  • IPv4 – nshttps-127.0.0.1-443
  • IPv6 – nshttps::1|-443

Proceed by opening the properties of nshttps-127.0.0.1-443 to display the configuration settings:

image

Navigate to the bottom of the list and click on Client Certificate to bring up the Client Cert Key window:

image

Note how the default 512-bit ns-server-certificate is binded as a Certificate already which is why the NetScaler administration GUI console listens on port 443 (https) but is rejected by web browsers.  A proper certificate should be 1024-bit or higher and the one I’ve installed for this example is 2048-bit as shown here:

image

Proceed by clicking on the Bind button to list the certificates available:

image

Select the certificate that you’ve imported in Step #1 and click on the Insert button:

image

image

Proceed with unbinding the default certificate (if you forget, the NetScaler will unbind it for you) and click on the Save button:

image

You should now be brought back to the previous page and with the certificate binded, proceed by clicking on the Done button:

image

With the new 1024-bit or higher certificate binded, your NetScaler GUI administrator console should now load properly via https:

image

image

Repeat Step #2 for the IPv6 NSIP nshttps::1|-443.

image

Step #3 (Optional) – Forcing https Access to NetScaler

Depending on the organization’s security requirements, policy may dictate that all traffic to the NetScaler’s GUI administration console must be encrypted so if this is the case, it is possible to disable http access to the NSIP.  Note that I’ve been asked many times whether there is a way to simply do a redirect and the answer is “I don’t know” as I have yet to come across information on how or whether this can be done so feel free to let me know if you do.

Begin by navigating to:

NetScaler –> System –> Network –> IPs –> IPV4s

… then select your NetScaler IP:

image

Open the properties page of the NSIP:

image

Navigate to the bottom of the configuration page and locate the Secure Access only checkbox:

image

Checking this checkbox will disable http access:

image

Once this has enabled, you will no longer be able to access the GUI via http:

image

Not surprisingly, I’ve been called several times about not being able to access the GUI administrator console after enabling this because of reasons such as there was something wrong with the certificate used for https traffic or the administrator forgot to bind the certificate.  While you cannot access the GUI anymore, you can still SSH over to the NetScaler to disable the Secure Access only option via command line. The command to disable forced https access is as follows:

set ns ip <NSIP> -gui enabled

Using the IP addresses in the screenshot above as an example, the command would look as such:

set ns ip 10.26.21.30 -gui enabled

Conversely, if you wanted to enable the Secure Access only option via CLI, the command would like as such:

set ns ip 10.26.21.30 -gui secureonly

-------------------------------------------------------------------------------------------------------------------------------------------------

Hope this helps anyone out there looking for instructions on how to secure NSIP GUI access.

Sunday, November 23, 2014

Troubleshooting Citrix NetScaler LDAP Authentication Issues

One of the changes I liked most about the NetScaler NS10.5 release was that the reliance on Java has finally been removed and replaced with HTML5.  I can’t count how many times I’ve been frustrated at a client’s office trying to make a simple change to their NetScaler but end up spending an hour getting Java to work.  With that said, it appears that one of the features that the old NetScalers provided, Create Authentication Server, no longer has the Retrieve Attributes feature to test your configuration:

image

Notice how the new 10.5 NetScaler’s Configure Authentication LDAP Server no longer has this option:

image

As simple as this Retrieve Attributes feature may seem, I found it extremely useful to quickly validate the configuration settings.  What I’ve noticed is that with this feature removed, I’ve been asked several times how would it be possible to troubleshoot simple errors such as typing in the wrong password for the service account.  The answer to this question is using the aaad.debug log as demonstrated in the following article:

How to Troubleshoot Authentication with aaad.debug
http://support.citrix.com/article/CTX114999

As an example, let’s say I made a mistake when typing in the password for the service account used by the NetScaler to perform LDAP lookups and when I try to sign in through the portal, I receive the following:

image

Incorrect credentials. Try again.

image

Being by launching the SSH client of your choice and connect to your NetScaler and type in shell to get into the Linux operating system:

image

Change to the /tmp directory where the aaad.debug log is stored:

image

Type in cat aaa.debug to display the contents of the debug file as items get logged:

image

Now reproduce the error by logging in again:

image

Viewing the SSH session will show that entries into the log are written to the aaad.debug file:

image

The following is the items written from the failed login:


root@ns# cat aaad.debug
Tue Nov 11 20:32:56 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[498]: main timer 1 firing...
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[784]: process_kernel_socket call to authenticate
user :terence-admin, vsid :9612
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[2592]: start_cascade_auth starting cascade authentication
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_drv.c[106]: start_ldap_auth Starting LDAP auth
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_drv.c[129]: start_ldap_auth attempting to auth terence-admin @ 10.26.10.30
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_drv.c[131]: start_ldap_auth LDAP referrals are OFF
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_drv.c[132]: start_ldap_auth LDAP referral nesting depth 0
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[629]: continue_ldap_init Connecting to: 10.26.10.30:636
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[2802]: register_timer setting timer 147
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[2871]: unregister_timer releasing timer 147
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[697]: ns_ldap_set_up_socket Server certificate hostname = NULL
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[705]: ns_ldap_set_up_socket Setting timeouts for SSL/TLS.
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[738]: ns_ldap_set_up_socket Set cert verify level 0
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[755]: ns_ldap_set_up_socket setting up for SSL connection to : 10.26.10.30:636
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[2802]: register_timer setting timer 148
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_drv.c[180]: receive_ldap_bind_event receive ldap bind event

Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[356]: ns_ldap_check_result checking LDAP result.  Expecting 97 (LDAP_RES_BIND)
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[391]: ns_ldap_check_result ldap_result found expected result LDAP_RES_BIND
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[221]: ns_show_ldap_err_string LDAP error string: <<80090308: LdapErr: DSID-0C0903C8, comment: AcceptSecurityContext error, data 52e, v2580>>
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[401]: ns_ldap_check_result LDAP action failed (error 49): Invalid credentials
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_drv.c[206]: receive_ldap_bind_event Got LDAP error.
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[2871]: unregister_timer releasing timer 148
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[2161]: send_reject_with_code Rejecting with error code 4001
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[2188]: send_reject_with_code Not trying cascade again
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[2190]: send_reject_with_code sending reject to kernel for : terence-admin
Tue Nov 11 20:33:26 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[498]: main timer 1 firing...
Tue Nov 11 20:33:56 2014
/home/build/rs_105/usr.src/netscaler/aaad/naaad.c[498]: main timer 1 firing...

I find the SSH session windows often difficult to read so I usually copy and paste the text into Notepad to parse through it:

image

Carefully reviewing the log will reveal the following line that is of interest:

Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_common.c[401]: ns_ldap_check_result LDAP action failed (error 49): Invalid credentials
Tue Nov 11 20:33:07 2014
/home/build/rs_105/usr.src/netscaler/aaad/ldap_drv.c[206]: receive_ldap_bind_event Got LDAP error.

The portal login error should begin to work once the password is updated correctly in the Authentication LDAP Server configuration:

image

Saturday, November 22, 2014

Notes on requesting and applying Citrix NetScaler VPX licenses on the My Citrix portal

I’ve found that many of my clients and colleagues get confused when trying to request Citrix NetScaler licenses which doesn’t surprise me because I felt the same way the very first time I tried to do it myself so I thought it would be good to write this short blog post to point anyone who asks me for clarification.

As shown in the following screenshots from the My Citrix portal:

image

… the NetScaler licenses are bounded to the Host ID of the appliance and there have been times in the past where I’ve been asked whether this was the host name which is actually incorrect.  The Host ID of the appliance is really a MAC address of one of the interfaces of the appliance.  The following are methods that can be used to locate the Host ID.

Method 1 – Via NetScaler GUI

Simply log into the administration web console of the NetScaler and review the System Information tab will show the host ID as shown in the screenshot below:

image

Method 2 – Via Shell

To retrieve it via command line, simply either access the console or SSH to the appliance, get into the Linux context by typing shell then executing the command:

lmutil lmhostid -ether

image

Method 3 – Via Hypervisor

What I’ve noticed is that the interface owning the host ID used for the license has always been the first network card assigned to the appliance:

00:50:56:a1:42:64

image

--------------------------------------------------------------------------------------------------------------------------------------------------

Now that we have the Host ID of the appliance, proceed by entering it into the Host ID field of the license allocation webpage (make sure you do not include the colons) to generate a license file.

image

Friday, November 21, 2014

Lync 2013 Client has PowerPoint, Whiteboard, Poll and Q & A greyed out

Problem

You’ve successfully deployed Lync Server 2013 and began testing features in the Lync 2013 client but quickly noticed that the following options are greyed out:

  • PowerPoint
  • Whiteboard
  • Poll
  • Q & A

image

Solution

While there could be various reasons why these options would be greyed out, one of the more obvious reasons is that you forgot to check the checkbox:

Conferencing (includes audio, video, and application sharing)

… during your Lync front-end server deployment:

image

To correct the issue, simply launch the topology builder and enable the feature

image

Once the option is enabled, publish the topology, launch the Lync Server 2013 – Deployment Wizard and rerun the Setup or Remove Lync Server Components to install the missing components:

image

image

Once completed, the options should now be available:

image

Wednesday, November 19, 2014

Deploying Microsoft Lync 2013 audio and video with Citrix XenApp 6.5

Those who may have come across my previous post about integrating Lync 2013 audio and video redirection to the local client:

Deploying Microsoft Lync 2013 audio and video within a Citrix XenDesktop 5.6 VDI
http://terenceluk.blogspot.com/2013/10/deploying-microsoft-lync-2013-audio-and.html

… may know that although the requirement for XenDesktop 5.6 is to use the XenDesktop 7 VDA, which renders XenDesktop 5.6’s Desktop Director unusable because it does not support 7.x VDAs, XenApp 6.5 published desktops is a supported configuration as outlined in the following Citrix document:

XenDesktop, XenApp and Citrix Receiver Support for Microsoft Lync 2013 VDI Plug-in
http://support.citrix.com/article/CTX138408.html

I haven’t actually been working with XenApp 6.5 over the last few months and so never tested the configuration but as I to do so today for a client with the legacy architecture, I thought I’d write this short blog post about the configuration.

Environment Information

Citrix XenApp Version: 6.5
Hotfixes: Rollup 3

imageimage

Lync Client: 2013
Version: 15.0.4454.1506
MSO: 15.0.4420.1017
Bit: 32-bit

image

Citrix Receiver: 4.2

Step #1 - Update Citrix Receiver on the HP t610 thin client to version 4.0

Begin by checking the existing version # of the Citrix Receiver installed onto the client connecting to the XenApp 6.5 server and update it to a version later than 4.1.02.

Step #2 - Enable EnableMediaRedirection on Lync 2013 Server

Ensure that the Lync Client Policy of users who will be redirecting to local devices has EnableMediaRedirection enabled.  The environment for this demonstration has all the users using the Global policy so executing the Get-CsClientPolicy -identity Global cmdlet will show the following

image

**Note in the above screenshot that EnableMediaRedirection is not enabled.

Proceed by using the following cmdlet to enable it:

Set-CsClientPolicy -identity Global -EnableMediaRedirection $true

image

Executing the Get-CsClientPolicy -identity Global cmdlet will now show the following:

image

Step #3 - Install Microsoft Lync VDI Plug-in on the client connecting to XenApp

--------------------------------------------------------------------------------------------------------------------------------------------------------

**Note that at the time of writing this post, only the 32-bit version of the Microsoft Lync VDI Plug-in is supported and will work for redirecting audio and video.  The 64-bit plug-in is not supported and will not work as described in the following Citrix article:

XenDesktop, XenApp and Citrix Receiver Support for Microsoft Lync 2013 VDI Plug-in
http://support.citrix.com/article/CTX138408.html

Citrix Receiver for Windows requires the 32-bit version of the Microsoft Lync VDI Plug-in on the device, even on a 64-bit Windows machine. The 64-bit version is not compatible with Citrix Receiver for Windows since the bitness of the VDI Plug-in must match the bitness of the Receiver.

--------------------------------------------------------------------------------------------------------------------------------------------------------

Proceed to download the Microsoft Lync VDI 2013 plugin 32-bit and install it onto the thin or thick client that will be used to connect to the virtual desktop:

http://www.microsoft.com/en-us/download/details.aspx?id=35457

Restart the thin client and you’ll notice that when you connect to your VDI, you will see a new green small icon at the bottom right hand corner with a white checkmark:

image

Clicking on it will show the following:

Lync is all set to use your local audio and video devices.

image

Note that unlike the thin client I was working with in my other post, I did not have to set the following registry keys on the Windows 7 full desktop I was using:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Lync

"ConfigurationMode"=dword:00000001" <—DWORD (32-bit) Value

"ServerAddressInternal"="yourLyncServer.domain.local" <—String Value

"ServerAddressExternal"="yourExternalEdge.domain.com" <—String Value

I believe the reason why is because the desktop I was using to connect to XenApp already had Lync 2013 installed on it and although the registry key above did not contain any of the items that had to get manually added to the thin client, the redirection still worked.  It is likely that these registry keys would need to get created if the computer was not joined to the domain.

Sorry about the brevity of this post but I just wanted to quickly demonstrate that this configuration also works with XenApp 6.5.