Firewall Port Requirements for Citrix NetScaler 10 and Citrix XenApp 7.6

I’ve noticed over the past year that one of the questions I get asked often is where to find specific Citrix documentation outlining the firewall port requirements and rules required to publish a XenApp environment through a NetScaler appliance and I find that every time I forward the following Citrix KB:

Required Ports for Citrix NetScaler Gateway in DMZ Setup
http://support.citrix.com/article/CTX113250

… I always get follow up questions about what is required for their environment so I thought I’d write a quick blog post supplying a diagram that provides a sample configuration.  The following example is a NetScaler deployed with two interfaces where one leg sits in an outside DMZ and the other on an inside DMZ.  Firewall rules are set up as shown in the following diagram between the DMZ networks and the internal server VLAN where the Citrix Delivery Controller, StoreFront, Application server and Active Directory Domain Controllers reside. The rules allow users to access the portal via http or https (http gets redirected to https) and the NetScaler is able to either use LDAP on port 389 or LDAPS on port 636 to authenticate against the domain controllers as well as communicate to the StoreFront server either http or https:

Note that the configuration above is simply a sample and may not work for every environment so I’m supplying it “as is” but hope that it would be able to help someone get started with their environment.

Unable to grant a mail enabled security group permissions to a resource calendar in Exchange 2013

Problem

You would like to grant a distribution group configured in an Exchange 2013 organization permissions to a resource calendar:

… so you open up the properties of the group:

… and change the Group type from Distribution to Security:

You proceed to use the Add-MailboxFolderPermissions cmdlet to add the distribution group as a reviewer but receive the following error:

Add-MailboxFolderPermission “<ResourceMailBox>:\calendar” -user <SMTPofGroup> -accessrights “Reviewer”

The user “<SMTPofGroup>” is either not valid SMTP address, or there is no matching information.

+ CategoryInfo: NotSpecified (:) [Add-MailboxFolderPermission], InvalidExternalUserIdException

+ FullyQualifiedErrorId : [Server=<serverName>,RequestId=3ad24ea6-18c4-4abd-97da-f875f50790c5,TimeStamp=1/16/2015 2:04:35 PM] [FailureCategory=Cmdlet-InvalidExternalUserIdException] E4DC5802,Microsoft.Exchange.Management.StoreTasks.AddMailboxFolderPermission

+ PSComputerName : <serverName.FQDN>

Solution

There are actually a few reasons why the error message above would be thrown and the obvious one is if the group isn’t a security group or, as the error message indicates, the SMTP address specified is not valid but for the situation I encountered, it wasn’t as obvious until I tried opening the resource calendar’s properties and add it via the GUI which was when I received the following error:

Microsoft Outlook

One or more users cannot be added to the folder access list.

Non-local users cannot be given rights on this server.

Seeing this error message immediately reminded me that because I had converted the group from distribution to security, I needed to set the group to restrict members from removing their membership with the following cmdlet:

Set-Distributiongroup -identity <GroupName> -MemberDepartRestriction Closed

Once I successfully executed the cmdlet above, I was then able to add the group as a reviewer to the resource mailbox’s calendar:

Unable to start the vCenter Site Recovery Manager Server service after migrating the SRM SQL database to another server

I was recently asked by a client to assist with migrating their current VMware Site Recovery Manager 5.1.1.7655 from one database server to another.  As I’ve done this in the past a few times, I figure it wouldn’t take me much time but to my surprise it too much longer than I thought so I figure this warranted a blog post in case I run into this again. 

I began by backing up the production SRM database to a BAK file, recreated the SQL Authentication account on the new SQL server, then restored the SRM database.  As I wasn’t the consultant who deployed this instance of SRM, I noticed that the database’s schema and owner was set to dbo and not the service account.  What the person who deployed SRM had done was simply make the service account an sysadmin on the database server which I figure I’d take the opportunity to correct so I used an old blog post I wrote for SRM 4:

Recovering / reinstalling SRM (Site Recovery Manager) 4.1.1 after suffering a host failure
http://terenceluk.blogspot.com/2011/10/recovering-reinstalling-srm-site.html

… to configure the schema and service account as per the following VMware KB:

Connecting to VMware vCenter Site Recovery Manager fails with the error: Unable to start Site Recovery Manager Service (1027973)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027973

The database schema has three requirements:

• It must be owned by the SRM database user (the database user name you supply when configuring the SRM database connection).
• It must be the default schema for the SRM database user.
• The database schema name must be the same as the database user name.

Then reconfigured the ODBC connector to point to the new SQL server but quickly noticed that when I try to start the VMware vCenter Site Recovery Manager Service service, I receive the following error:

Windows could not start the VMware vCenter Site Recovery Manager Server service on Local Computer

Error 1067: The process terminated unexpectedly.

Unfortunately, the event logs doesn’t provide much more information than an Event ID: 7034 error with the message:

The VMware vCenter Site Recovery Manager Server service terminated unexpectedly. It has done this 4 times(s).

What was strange was that if I made the service account a sysadmin, the service would start:

After combing through setting after setting between the two SQL servers and not finding any differences other than having configured the service account the correct way, I noticed that when I browse the restored database properties on the new server, navigate to the Files page, the Owner field was blank:

Attempting to assign the service account would fail because it indicates that account already has the mapping. So I went ahead and removed the database mapping from the service account’s properties then went back into the database’s properties to assign the owner as the service account and this time it worked.  Reviewing the User Mapping tab now shows the following:

It’s a big strange that the screenshot above lists the user and default schema as dbo while the Owner for the database properties is listed as the service account:

… but the service now starts:

I explained the situation to the client and proposed that it is possible to try and reconfigure the mappings back to what we expect it to be and try a SRM reinstall mimicking a server loss issue but the client was ok with the current configuration for now.

Hope this helps anyone who may come across such a situation and unable to actually perform a reinstall of SRM.

Deploying VMware vCenter Operations Manager with Operations Manager for Horizon 1.7

One of the clients I’ve been working with over the past few months have had interest in seeing what the vRealize Operations for Horizon had to offer in terms monitoring metrics and alerts so we went and deployed the solution in the environment as a pilot.  As with most products I have the opportunity to deploy but know that I won’t be doing this on a frequent basis, I’ve taken screenshots of the process to write this blog post so I can have something to refer to in the future when I want to remember what the deployment process looks like.

Note that the VMware vCenter Operations Manager For Horizon 1.7 product is actually an add-on for the VMware vCenter Operations Manager so prior to actually installing this module for VMware Horizon View, you’ll need to ensure that the vCenter Operations Manager 5.7.2 vApp is deployed and running properly in your environment.

Begin by download the vCenter Operations Manager 5.7.2 vApp (or whatever the latest supported release is) and deploy the OVF:

Note the newly deployed vApp with two virtual machines:

The following are the specs for the Analytics VM:

The following are the specs for the User Interface VM:

You’ll need to create an IP Pool prior to powering on the two vApp VMs so click on the Datacenter object, then the IP Pools tab and then the Add... button:

Give the IP Pool a name and configure the subnet and IP range that the vApp would be using:

Note that since we’ve configured the IP allocation policy during the OVF deployment to be:

Fixed

IP addresses are manually configured.
No automatic allocation is performed.

… this IP Pool actually wouldn’t be used but it appears the vApp requires one to be configured in order to power on.  These IP addresses would be used if we’ve chosen the Transient option.

Proceed by powering on the Analytics VM then the UI VM and then use a browser to navigate to the IP address of the UI VM:

Login with the default credentials admin/admin and proceed with configuring the vCenter server that the vApp will be connecting to:

Change the password to the vApp as required:

The following Registration page will be displayed once the registration to vCenter has been completed:

Proceed by clicking on the Update tab:

Then click on the Browse button to upload Operations Managers packages:

Agree to the EULA:

Now repeat the same for the other packages:

Now finally the Horizon View 1.7 package:

With the packages uploaded, the next step is to add the license for vCenter Operations Manager so that the License Mode is not listed as Foundation:

Proceed by restarting the vApp virtual machines then log into the vCenter Operations Manager portal and you should now see the License Mode is set to Advanced:

With the vCenter Operations Manager licensed, continue by navigating to the main page https://<UI-VM-IP> and log in to the vCenter Operations Manager monitoring console page:

Hoover the mouse point over ADMIN and then click on SUPPORT:

Click on the Info tab:

Hoover the mouse pointer over the ENVIRONMENT tab then CONFIGURATION > then ADAPTER INSTANCES…

Select vCenter Operations Standard Server for the Collector and V4H Adapter for the Adapter Kind then click on the Add New Adapter Instance icon:

Type in a name for the Adapter Instance Name, set Metric Set to Full Set and click Add for Credential:

Configure the following:

Adapter Kind: V4H Adapter

Credential Kind: Pairing Credential

Instance name: Provide a name for the instance

Server Key: Type in a key of your choice

Click on the Test button to test the configuration:

Click on the OK button in the Manage Adapter Instances window to confirm the addition:

Click OK again to confirm the addition:

With the adapter configured in vCenter Operations Manager, proceed by logging on to your VMware Horizon View Connection server and installing the VMware vCenter Operations Manager View Broker Agent:

Continue by configuring the agent:

Type in the address for the Analytics VM:

Enter the paring key created earlier:

Type in a service account credentials to connect to the View administrator:

Type in a service account credentials to connect to the events database:

Proceed through the wizard and configure the setting:

With the agent configured, you should now see data populating the dashboard:

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

That’s it for the deployment.  Please note that I’m not an expert with the vCenter Operations Manager product and this post is just for demonstrating what the steps look like for the deployment.