Monday, January 26, 2015

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:

image

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.

Monday, January 19, 2015

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:

image

… so you open up the properties of the group:

image

… and change the Group type from Distribution to Security:

image

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>

image

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.

image

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

image

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

image

Thursday, January 15, 2015

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.

image

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.

image

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).

image

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

image

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:

image

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:

image

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:

image

… but the service now starts:

clip_image002

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.

Sunday, January 11, 2015

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:

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

Note the newly deployed vApp with two virtual machines:

image

The following are the specs for the Analytics VM:

image

The following are the specs for the User Interface VM:

image

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:

image

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

imageimageimage

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.

image

… 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:

image

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

image

Change the password to the vApp as required:

image

image

image

image

image

image

image

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

image

Proceed by clicking on the Update tab:

image

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

image

image

image

image

image

Agree to the EULA:

image

image

image

image

image

image

image

Now repeat the same for the other packages:

image

image

image

image

image

image

Now finally the Horizon View 1.7 package:

image

image

image

image

image

image

image

image

image

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:

image

image

image

image

image

image

image

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:

image

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:

image

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

image

Click on the Info tab:

image

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

image

image

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

image

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

image

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

image

Click on the Test button to test the configuration:

image

image

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

image

Click OK again to confirm the addition:

image

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:

image

image

image

image

image

image

image

image

Continue by configuring the agent:

image

Type in the address for the Analytics VM:

image

Enter the paring key created earlier:

image

image

image

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

imageimage

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

imageimage

Proceed through the wizard and configure the setting:

image

image

image

image

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

image

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

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.