Pages

Monday, January 26, 2015

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:

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

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:

Thursday, January 15, 2015

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:

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.

Sunday, January 11, 2015

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.