Citrix recently announced an Implementation Guide for Microsoft Office 365 for Citrix XenApp and XenDesktop 7.x. After reading their recent deployment guides I noticed several mistakes which makes very clear to me that the writers may understand Citrix very well but not the Microsoft technologies and products. Now the purpose of these documents is to make sure that our customers and partners understand the technologies well enough to guarantee a successful implementation. I really wonder why they don't have a Subject Matter Expert proofreading the documents before they get released. Let me give a few examples.
The latest document starts with an error in the first paragraph:
Office 365 ProPlus includes a combination of online-based applications (Outlook, Word, Excel, PowerPoint and OneNote) that are accessed from anywhere via a web browser, as well as the latest traditional, locally installed version of Microsoft Office.
No it's not, Office ProPlus is the locally installed version of Microsoft Office.
Included with Office 365 ProPlus is an online email account with 50GB of storage and 1TB of file storage per user with OneDrive for Business.
No it's not, Office 365 ProPlus is not the name of one of the Office 365 subscriptions, it's the version of Microsoft Office you install on your computer.
Another example is Deploying Citrix NetScaler with Microsoft Exchange 2013 for GSLB.
Per service health checks, single unbound namespace, stretched DAG, nice! But why is there a CAS server in the DAG? Or more important, why is the DAG load balanced? When talking about Exchange high availability it's key to have a good understanding of the difference between Client Access HA and Mailbox data HA. The traffic to the Client Access servers is load balanced. Mailbox servers in a DAG enable the organization to deploy multiple copies of the database and store them on another DAG member server. The Client Access servers proxy the user's request to a Mailbox server.
Different clients add different suffixes to the domain name when they connect to virtual server. For example, /owa for web browser clients, /oa for Outlook anywhere.
That's the /rpc virtual directory, not /oa.
NetScaler GSLB also enables to maintain availability in case of site level disaster in which one of the sites is completely unavailable. This is shown in Figure 4. When there is hot sync between the mailbox servers and the user information is available on all the mailbox servers, then all the requests of site 1 can be completely served from site 2.
What is hot sync between the mailbox servers? I suppose the writer means that the database has a replica or copy on a server in the second site.
And then there is the Guide to Deploying Microsoft Exchange 2013 with Citrix NetScaler.
A snippet from a bit complex drawing. All servers, including the domain controllers are multi-homed. This is at least very uncommon and certainly not according best practices. And again there's a (single?) CAS server in the DAG that does not belong there. It should've been at least two CAS servers to demonstrate load balancing of the CAS servers.
And then there's the split-role/multi-role debate, where Microsoft recommends to deploy multi-role servers since the 2010 timeframe and still does for 2013. I guess the writers tried to update the document by writing "Exchange 2013 Multirole Servers MB/CAS" under the picture but forgot to actually update the diagram.
Is not going to work, oa needs to be rpc.
In the configuration shown above, a single namespace is used for all Exchange protocols. For example, for web access, the namespace is https://mail.ctxns.net/owa, and for Outlook clients the namespace is https://mail.ctxns.net/oa.
It's still /rpc, not /oa. And where is /Autodiscover, did we forgot this one?
More important flaw of the document is that the first half is the copy and past of some TechNet articles and some slides Microsoft presented at a tech conference, the seconds halve is just a series of screenshots. For me as an Exchange admin it does not really explain an good overview of load balancing with NetScaler, it does not dive in to the details as for instance session time-out settings, why we use least connection and if we can configure a slow start time to prevent an overloaded server after a reboot, transparent or non-transparent load balancing, routing considerations, etc.
And from a load balancer perspective I'm not sure how well the NetScaler guy understands load balancing an Exchange 2013 solution after reading the deployment guide. Especially with the small mistakes and bad representation of the architecture (mainly in the GSLB document).
Let's wrap-up my complaints with a positive remark. The latest version of the document is an improvement over an older version which had a dedicated set of Client Access servers in the perimeter network. I'm being sarcastic of course, I think there's room left for improvement. I mean the NetScaler is an interesting product, especially for customers looking for a CAG replacement. But when it comes to documentation and ease of configuration other vendors as KEMP Technologies have a better story. Personally I prefer an affordable load balancer with excellent documentation by a company who shows they understand their work loads over a powerful network appliance which is too complex to configure correctly and lacks proper documentation. This is where Citrix can learn from KEMP technologies.
1 comment:
As a MS Engineer who frequently does Netscaler, I mean ADC, deployments I laughed in agreement numerous times reading through this. After a lot of wasted time troubleshooting after using their guides I developed my own config and have been using it ever since. Fortunately load balancing is effectively the same 2013 and up so we haven't had to reinvent the wheel each time. Anyway, I thoroughly enjoyed reading this. Thanks for writing it.
Post a Comment