Think IPM

Monday, January 25, 2016

Director Alerts! Configuring for Office 365

Figured this would be an appropriate time to send this email, with all of the snow out there inthe North East, many administrators may be working remotely. Having a process looking in on the health of your Citrix environment and reporting if any issues arise would be just wonderful! Well fear not, Citrix has thought of this already and with the latest version of Director, v7.7, they have added in the capability to create triggers to alert you to any potential issues as they come up. Of course our systems don’t have much use for alerts as they don’t have any issues! Smile
After you install (or upgrade) your Director and log in, you will notice a new option in the title bar called Alerts:
Clicking on this new option will take you to the Alerts area where you can set up all sorts of triggers, I will leave this to you to sort out. What I wanted to discuss is how to get those alerts to be emailed out in an Office 365 world as it might not be so evident.
Click on the Alerts option and then the Email Server Configuration tab.
This will bring you to the email relay configuration. From this screen you have several pieces of information that you will need to provide. If you are in an Office 365 environment, you might have already configured other devices to send email out. There are two main ways to accomplish this, 1) via an onsite relay and 2) via direct authentication. The second choice is the more preferably one according to Microsoft. There are many articles out there already on how to set up a SMTP relay, so we I will focus on the second option.
Back to the tab, ok, so right off the bat, there is a mistake in the interface, so for the first choice, Protocol, if you pull down the drop-down, you will see the following options:
Office 365 requires SMTP-TLS, but Director seems to only have an option for a *new* protocol called SMTP-TSL! Ok, maybe not a big deal, but it made me take a second look, select this option, even if it feels wrong, don’t worry the option doesn’t stay wrong for long.
For Office 365 use the following choices:
Host: Port: 587 Sender Email:
Does SMTP server require authentication: Yes User Name:
You should have noticed that as soon as you selected the SMTP-TSL option, it immediately corrects itself and changes to SMTP-TLS. As for the other settings, namely the email address, most places have an email account that they use to send alerts for other things already, so this same account can be utilized here. You can use the same email address to be the sender as the one to do the sending. If you choose to have the alerts come from one email address and authenticate using a different one, make sure that you assign the correct send on behalf of permissions to allow the account to send properly.
That’s it, once this is completed, click on Save and feel free to send a test message. As soon as you click the Send Test Message button it will immediately ask you to enter in an address to send the message to. If all is ok, you should get something that looks similar to this:
If you don’t get the email, you might want to make sure that you don’t have a firewall blocking the port. Once you receive the email, you are good to go and can click through the other tabs to set up all of the alerts you are interested in being made aware of!
Click Here to Continue Reading >>

Thursday, December 17, 2015

Vote for IPM @ the Citrix Demo Derby

Here is a shameless plug for my company.  ;) If that sort of thing bothers you, look away now and click here.
My colleagues spent a good amount of time putting together a great video highlighting both Citrix Mobile Technology and New York City!
This great video was created by Rick Passero, Paul Kilgallen, and Citrix’s Aida Luu for the Citrix Partners’ Demo Derby, a contest among Citrix’s partners for showcasing their products.  
They have made it to the finalist round which is determined by public voting so help IPM win and vote here!  Winners will be announced at Citrix Summit in January.
Click Here to Continue Reading >>

Tuesday, November 24, 2015

VMware 6 : Unable to connect to the MKS: Internal Error

Almost EVERY SINGLE time I see this error, it’s DNS related.  When I ran into it tonight, I immediately thought I had fat fingered the DNS entries in the VMware vCenter Appliance Deployment wizard. 
This became an interesting chicken and egg scenario – I needed to check my DNS settings on the Console but of course, couldn’t get a console for the VM!  Doh!
Fortunately, I had enabled SSH when deploying the vCenter Appliance (Something I will continue to ALWAYS do!).  A quick putty over to the vCenter VM and everything looked fine…  What gives?
Image result for crumpled up paperTime to search the VMware Knowledge Base.  After some searching, I ran across this:
In this particular project, I was migrating hosts from a Windows based vCenter to a vCenter Appliance and apparently when I migrated the existing hosts over to the new vCenter Appliance, some certs got borked.
Quick Fix: vMotion EVERYTHING from one host to the next and everything was back to normal.  Whew!
Click Here to Continue Reading >>

Monday, November 16, 2015

VMware View 6.2 XP Support issues.

image Recently, I was working with a client on an upgrade to their VMware View environment. We were upgrading from View 5.2 to 6.2. A nice jump in versions that was hopefully going to go pretty painlessly. The majority of the machines were Windows 7 machines with a sprinkling of Windows XP machines that for various support reasons were pretty critical to a select few people. Once we had the outage window, we moved to begin upgrading the View infrastructure servers. All went good but when recomposing the XP pool, none of the Virtual Machines were registering with the Brokers. On the broker screens, I was receiving errors complaining about network communications:

No network communication between the View Agent and Connection Server. Please verify that the virtual desktop can ping the Connection Server via the FQDN

After your normal troubleshooting based on this catch all KB Article,  I came across this gem in the release notes regarding XP support:

Supportability of Windows XP and Windows Vista guest operating systems as desktop virtual machines
The versions of View Agent that ship with Horizon 6 (version 6.1) and later releases do not support Windows XP and Windows Vista desktops. The Horizon 6 (version 6.1) servers will work with Windows XP and Windows Vista desktops if you continue to use the older View Agent 6.0.2. The older agent, of course, does not offer all of the features of the new agent.

Unfortunately, rolling back the Agent version on the images still not allow the XP VMs to register with the Brokers.  In the inventory screens, the agent versions were still showing up as unknown.

I was starting to give up hope.   Fortunately with some unreproducible Google-fu, I came across this KB article that saved the day.

How to change a Horizon 6 version 6.1 environment from Enhanced message security mode to Enabled security mode

Apparently, after 6.1, there were some changes in the way that the Desktop Agents communicated to the Brokers that were not supported by the older 5.x agents.  In order to enable communications between the older agents and the newer brokers, some ADSI hacks had to be made.  This basically dumbed down the communications to allow the agents to communicate and more importantly register with the brokers.

A quick reboot of the Brokers and the older XP VMs were registering successfully with the Brokers.  I still don’t remember how I managed to come across this needle in the Knowledge Base Haystack but I figured I’d write a quick blog post about it so I don’t forget it. :)

Enjoy enabling your user base to hang on to their XP machines for just a little bit longer!

Click Here to Continue Reading >>

Thursday, October 22, 2015

Easy Hotfix list for Microsoft TS/RDS patching

Image result for listTracking down patches is a pain in the ASCII.  You want to keep your servers up to date but digging through endless Google searches to find relevant KB articles for each operating system is no fun. 

Aaron Silber feels your pain and sent over this handy-dandy table that takes you to the Microsoft pages of updates available on TS/RDS.

Terminal Services (Remote Desktop   Services) in Windows Server 2008

KB 2312539

Remote Desktop Services (Terminal   Services) on Windows Server 2008 R2 SP1

KB 2601888

Remote Desktop Services in Windows Server   2012

KB 2821526

Remote Desktop Services in Windows Server   2012 R2

KB 2933664

That’s quite the treat for Halloween! Thanks Aaron!

Click Here to Continue Reading >>