Pages

Sunday, November 18, 2012

Federation no longer works after moving user to new Lync Server 2013 pool to Lync Server 2010 during coexistence

I’ve noticed that I’ve been asked several times about why federated contacts are no longer reachable after a user is moved from a Lync Server 2010 pool to a Lync Server 2013.  The following are the symptoms.

Problem

Federated contacts are shown as Presence unknown:

image

Attempting to message the federated contact displays the following message:

We couldn’t send this message because we couldn’t find <ContactName>.

image

No errors or warnings are logged on the legacy Edge server, the front-end servers and snooper logs does not reveal any errors related to this.

Solution

The solution to this is actually quite simple because of all the times I reviewed the configuration of a newly deployed Lync Server 2013 pool that is coexisting with a Lync Server 2010 pool, the issue is usually because the administrator forgot to associate and enable SIP federation for the new Lync Server 2013 pool with the Edge server. 

To enable SIP federation for the new Lync Server 2013 pool, open up Topology Builder, right click on the site and click on Edit Properties…:

image

Scroll down to the Site federation route assignment section:

image

Check the checkbox Enable SIP federation, select the legacy Edge server and click OK to apply the changes:

image

With the SIP federation configured, proceed with expanding the nodes to Lync Server 2013 –> Enterprise Edition Front End pools –> yourPool then right click and select Edit Properties…:

image

Scroll down and locate Associate Edge pool (for media components):

image

Check the checkbox for Associate Edge pool (for media components), select the legacy Edge server and then click OK to apply:

image

Continue by publishing the topology to apply the changes.  Note that if you don’t immediately see the federated contacts listed a reachable, restarting the front-end services will force the changes to take effect.

image

Note that the steps above can be found in the following TechNet migration guide:

Connect Pilot Pool to Legacy Edge Servers
http://technet.microsoft.com/en-us/library/jj721875.aspx

Saturday, November 17, 2012

Citrix NetScaler VPX 1000 version 10 management interface does not load

As most administrators of the Citrix NetScaler VPX 1000 appliance know, while the location of configuration settings remain the same, the look and feel of the management interface has gone through a change from version 9.3 to 10.  I haven’t had any issues with the management interface in the past with version 9.3 but experienced a frustrating issue with version 10 today where I could not load the administration web interface once I’ve logged in.  The following is the appliance information I was using:

Version

  • NS10.0
  • Build 71.6.nc
  • Date: Oct 14 2012
  • 06:39:56
    image

    What basically happens that I will navigate to the management web interface and get presented with the login page:

    image

    Logging in works fine but once authenticated, I get presented with the following blank page:

    image

    Notice the little exclamation mark at the bottom left hand corner.  Clicking on it brings up the following window:

    Errors on this webpage might cause it to work incorrectly

    To see this message in the future, double-click the warning icon on the status bar.

    ‘2’ is null or not an object

    neo.js

    Exception thrown and not caught

    rdx.js

    Code: 0

    URI: http://yourNSIP/admin_ui/rdx/core/js/rdx.js

    image

    I’ve tried this on the following Java and IE versions:

    IE: 8.0.7600.16385

    image

    Java:

    • Version 7 Update 9 (build 1.7.0_09-b05)
    • Version 6 Update 32 (build 1.6.0_23-b05)

    imageimage

    What’s strange is that if I were to change the URL in the browser from:

    http://someIPaddress/menu/neo

    … to…

    http://someIPaddress/menu/guia

    … which is the URL used in the version 9.3 or earlier NetScaler, I would be able to get the administration page to display in the older version 9.3 look and feel:

    image

    The only way I was able to fix this was to upgrade Internet Explorer from version 8 to version 9 and use Java 7.

    When I use Internet Explorer version 9 with Java 6 Update 32, I receive the following error:

    We were unable to return you to the page you were viewing.

    Internet Explorer has stopped trying to restore this ewbsite. It appears that the ewbsite continues to have a problem.

    image

    Wednesday, November 14, 2012

    Migrating Citrix XenApp 6.5 data store database from one SQL server to another

    I’ve been meaning to write a blog post for migrating Citrix a XenApp 6.5 data store database from one SQL server to another as this is quite common to do whether it’s due to server refreshes, disaster recovery or other similar situations.  First off, there are various Citrix documents available on the internet that describes the process and they are found in the following links:

    Data Store Migration Strategies
    http://support.citrix.com/article/CTX123111

    How to Move or Migrate Data Store on XenApp 6 to another Server
    http://blogs.citrix.com/2010/06/03/how-to-move-or-migrate-data-store-on-xenapp-6-to-another-server/

    Migrating a Farm Data Store from MSDE to SQL Server Express
    http://support.citrix.com/proddocs/topic/xenapp5fp2-w2k3/ps-datastore-migrate-msde.html

    The problem I have with these documents are that they don’t describe the process in details and some of them omit various steps.  In a situation where you’re pressed for time or have already been working for extended hours having to response to an emergency, it’s not pleasant at all to fill in the gaps and this is why I thought I’d blog the steps incase I ever find myself in such a situation.

    Let’s start with a bit of background information about the environment:

    Citrix XenApp version: 6.5

    Production SQL Database: SQL Server 2008 R1 | Build: 10.0.5500

    Production SQL Database Server and instance: SVR-SQL-04\Citrix

    Destination SQL Database: SQL Server 2008 R2 | Build: 10.50.1600

    Production SQL Database Server and instance: SVR-SQL-06\Citrix

    XenApp Servers:

    • SVR-CXA-01
    • SVR-CXA-02

    Stop the IMA (Citrix Independent Management Architecture) Service

    The Citrix documentation doesn’t explicitly state that you need to stop the IMA service but logically thinking about it makes me believe that it should be stopped to avoid any writes to the SQL database.  I’ve tried this in a production environment and have not seen any issues but whether you choose to stop it or not will be your choice.

    imageimage

    Back up XenApp data store Database

    Once the IMA service has been stopped on all of your XenApp servers in the farm, proceed with launching Microsoft SQL Server Management Studio on the production SQL server and navigate down to the database:

    image

    Right click on the database and select Tasks –> Backup:

    image

    From within the Back Up Database window, remove the default Destination path:

    image

    … then click on the Add button:

    image

    In the Select Backup Destination window, click on the button and navigate to the destination path where you want to backup the database:

    image

    For this example, we’ll be using the C: and naming the file XenApp65.bak:

    image

    Click on the OK button and then again in the Select Backup Destination window:

    image

    In the Back Up Database window, confirm the settings and click on the OK button to proceed with backing up the database:

    imageimageimage

    Create the XenApp database service account on the new SQL server

    Prior to restoring the database, we’ll need to create the XenApp database server account on the new server so that when we restore the database, the restore will retain the service account dbowner assignment:

    image

    image

    image

    image

    Restore XenApp data store Database

    With the XenApp database service account created on the new production SQL server, begin by copying the backed up database file onto the new server:

    image

    image

    … and then proceed with restoring the backed up database by right clicking on the Databases node and select Restore Files and Filegroups…:

    image

    From within the Restore Files and Filegroups window:

    image

    … select From device and click on the button:

    image

    Within the Select backup devices window, ensure that the Backup media type is selected as File then click on the Add button:

    image

    Locate the backed up database and click OK:

    image

    Continue and click on the OK button again:

    image

    From within the Restore Files and Filegroups window, type in the same XenApp database name into the To database field, ensure that the Restore checkbox is selected and then click on the OK button to commence the restore:

    imageimage

    image

    Note that the database isn’t immediately revealed after the restore so use the F5 button to refresh the list:

    imageimage

    Updating the DSN for XenApp’s connection to the new SQL server

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

    From here, the Citrix blog post:

    http://blogs.citrix.com/2010/06/03/how-to-move-or-migrate-data-store-on-xenapp-6-to-another-server/

    … suggests that we use the ODBC Data Source Administrator:

    image

    to reconfigure the mf20.dsn file but what I’ve found in the past is that using this tool adds and somewhat changes certain values in the mf20.dsn.  Note the following differences:

    Original mf20.dsn:

    image

    New mf20.dsn created by the ODBC Data Source Administrator:

    image

    Note how the ordering is a bit different and the new and modified fields:

    • WSID
    • APP

    Since the mf20.dsn is simply a text file, I choose to just use Notepad to edit the parameters.

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

    With the previous stated, I personally prefer to just open up the mf20.dsn file located in the directory:

    C:\Program Files (x86)\Citrix\Independent Management Architecture

    image

    … with notepad and edit the following fields:

    • Server

    image

    Simply update the server FQDN to the new server:

    image

    Start the IMA service and execute dsmaint config

    With the mf20.dsn updated, proceed with starting the IMA service:

    image

    … then use the dsmaint config command:

    dsmaint config /dsn:"c:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn"

    … to connect to the data store with new configuration settings:

    C:\>dsmaint config /dsn:"c:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn"

    Attempting to connect to the data store with new configuration settings.

    Successfully connected to the data store.

    Configuration successfully changed.

    Please restart the IMA Service for changes to take effect.

    image

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

    Note that if you receive the following error:

    C:\Program Files (x86)\Citrix\Independent Management Architecture>dsmaint config /dsn:mf20.dsn

    Attempting to connect to the data store with new configuration settings.

    Failed to connect to the data store. The settings will be reverted to the previo

    us configuration.

    Unable to change configuration settings.

    Please verify parameters and data source.

    C:\Program Files (x86)\Citrix\Independent Management Architecture>

    image

    It’s because you need to specify the full path to the mf20.dsn file and that simply changing the directory to its location will not work.  The following Citrix KB mentions this: http://support.citrix.com/article/CTX108699

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

    Once the dsmaint config executes appropriately, proceed with restarting the IMA service:

    image

    Verify New Data Source

    With the data source updated to point to the new server, proceed with taking the original production database offline:

    image

    … then opening up the registry on the XenApp server, navigate to:

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\

    … then review the value of the DataSourceName key (Type: REG_SZ) to ensure that the path and file is correct:

    image

    Once the data source registry key has been verified, continue by testing the XenApp server’s functionality but launching applications through the Web Interface.

    Repeat for other XenApp Servers

    Once we have verified that the updated XenApp server is in working order, proceed by repeating the following steps on each of the other servers in the farm.

    Copy the mf20.dsn file to the other servers:

    image

    Run the following command:

    dsmaint config /dsn:"c:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn"

    image

    Restart the IMA service:

    image

    Verify the registry DataSourceName key value:

    image

    Test the XenApp Server by launching applications.

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

    Hope this helps anyone out there looking for more detailed instructions on how to migrate a XenApp 6.5 farm’s SQL database to another server.