With a little over 6 months, here’s what’s new:

Toolbox #012: Citrix UPM Reset Tool

• Blog: https://www.cloudsparkle.be/2020-10-31-PSHostInfo/
• GitHub: https://github.com/Cloudsparkle/PSHostInfo
• Summary: Citrix UPM reset framework

Toolbox #013: IISLogMonitor

• Blog: https://www.cloudsparkle.be/2021-03-17-CTXAutolaunch/
• GitHub: https://github.com/Cloudsparkle/CTXAutoLaunch
• Summary: A PowerShell tool to continuous IIS Log file monitoring

Toolbox #014: FAS-CertCheck

• Blog: https://www.cloudsparkle.be/2022-03-29-FAS-CertCheck/
• GitHub: https://github.com/Cloudsparkle/FAS-CertCheck
• Summary: Powershell scripts to check certificates for Citrix FAS

Toolbox #015: PS-ScheduleTask

• Blog: https://www.cloudsparkle.be/2022-06-08-ScheduledTasks/
• GitHub: https://github.com/Cloudsparkle/PS-ScheduleTask
• Summary: Scheduled Tasks done in a special way.

Toolbox #016: A simple provisioning tool

• Blog: https://www.cloudsparkle.be/2022-06-16-PSApplaunch/
• GitHub: https://github.com/Cloudsparkle/PS-AppLaunch
• Summary: A framework to launch published applications

Toolbox #016 was a big one for me, one that I look forward to in developing further in the future. Please get in touch with any questions or suggestions!

That’s it for now. Stay tuned for more and above all: stay safe.

Thank you

Bart Jacobs

CTP

So I guess an update was, to say the least, overdue.

Let’s jump right in:

Toolbox #007: PSHostInfo

• Blog: https://www.cloudsparkle.be/2020-10-31-PSHostInfo/
• GitHub: https://github.com/Cloudsparkle/PSHostInfo
• Summary: A PowerShell based version of the old tool HostInfo

Toolbox #008: CTXAutolaunch

• Blog: https://www.cloudsparkle.be/2021-03-17-CTXAutolaunch/
• GitHub: https://github.com/Cloudsparkle/CTXAutoLaunch
• Summary: A PowerShell tool to launch Citrix Published resources (automatically).

Toolbox #009: Citrix UPM fix

• Blog: https://www.cloudsparkle.be/2021-07-27-UPMFix/
• GitHub: https://github.com/Cloudsparkle/Citrix-UPM-FileFix
• Summary: Some PowerShell to fix file permissions on Citrix UPM.

Toolbox #010: Counting Session Logon and Logoff

• Blog: https://www.cloudsparkle.be/2021-09-30-CTXSessionActivity/
• GitHub: https://github.com/Cloudsparkle/CTXSessionActivityCounter
• Summary: Count those session logon and logoff events with PowerShell

Toolbox #011: A simple provisioning tool

• Blog: https://www.cloudsparkle.be/2021-10-13-PS-ADUserRoleProv/
• GitHub: https://github.com/Cloudsparkle/PS-ADUserRoleProv
• Summary: Provide a simple tool to provision application resources.

That’s it for now. Stay tuned for more and above all: stay safe.

Thank you

Bart Jacobs

CTP

See what I did there? Some sneaky clickbait. But just keep reading; I promise the rest of the article is not.

It’s not THE truth either. It doesn’t even want to be. It’s my own view on the world EUC today.

Initially, I was about to write something just on Citrix. While correct, it would only be part of the story. There are other EUC vendors out there, and they are all facing similar issues. 

We’ve all been there. The end-user reports that his Business Application is not working to their liking by some form of communication.

That kind of message can go two ways:

• “I’ve got a Citrix problem because of Application X malfunctions.”*
• “Application X does not work, so it has to be a Citrix problem.”*

*Replace Citrix with EUC Vendor of choice

EUC vendors have been innovating at an extraordinary pace. Gone are the days when we have to wait for a significant OS release to get some shiny new code bits. It’s always changing; to that extent, it can be a real struggle to keep up.

But does this matter to the end-user? Not really; they just want their Business App. They don’t care if the technology provides a watermark, prevents them from taking a screenshot, etc. They wish to use their application to get their job done.

When the application doesn’t work, however, the application rarely gets the blame. It will be EUC technology. Even the original developers of the application can be reluctant to accept responsibility and just blame “Citrix” or whatever. 

As EUC admins, operators, specialists, (insert fancy job title here), … we’re often caught in the middle of this. We will be called upon to explain “why” it doesn’t work. And we always have been, since the dawn of EUC technology. You could even say, EUC engineers were the very first DevOps engineers. 

Let me unpack that.

DevOps originates from 2 words:

• Development: the creation of new stuff
• Operations: making sure that (new) stuff keeps running

 So, why am I calling EUC engineers DevOps Engineers then?

• Operations: we need to make sure things keep running. It can be as a day to day job or to come up with a design that maximizes this simple fact: the App needs to be available.
• Development: we don’t write “real” code. Not the application code itself anyway. We might need to write scripts to mitigate some application shortcomings. But more than anything, we develop the solution. The solution to the end-users problem: get that working Business Application.

So, let’s reconsider for a moment. EUC engineers will need to answer the question of why it doesn’t work. So why “operations” of the application is impacted. And we’ll be asked to fix it or to put in another way: to develop the solution.

Technology will and can help us with both of those tasks. But technology by itself will never be the solution. It will help us get there. Sometimes so fast we don’t realize it. But it will always be “the tool” that will help us get there, not the endpoint of the journey of fixing something.

To wrap up this blog post, this is a question to all EUC vendors out there: if you can’t explain why (new) technology will help us solve issues or make it better in general, go back to the drawing board and come back when you can.

Technology doesn’t matter; it’s about the people knowing how to make the most of it.

My very first post was also published on this very site here: https://www.carlwebster.com/bart-jacobss-toolbox-copyadgroupmembers/). For the posts that followed, I didn’t do that anymore.

No regrets, but I feel it’s about time to revisit this site and to publish an overview of what I’ve been up to.

To kick things off, let’s get this out of the way. Every script/tool I’ve published on this here is now also present on Github:

• XenGhost: https://github.com/Cloudsparkle/XenGhost
• XenApp Server Monitor: https://github.com/Cloudsparkle/XenApp-Server-Monitor
• XenApp Server Health Check: https://github.com/Cloudsparkle/XenApp-Server-Health-Check
• HostInfo: https://github.com/Cloudsparkle/HostInfo
• Deploy Printer Drivers: https://github.com/Cloudsparkle/Deploy-Printer-Drivers

I’m not really planning anything for them; I just want them out there to make my GitHub “complete” in a certain way.

That’s it for my “legacy” tools. Let’s continue with the new stuff already.

Toolbox #001: CopyADGroupMembers

• Blog: https://www.cloudsparkle.be/2020-03-31-CopyADGroupmembers/
• GitHub: https://github.com/Cloudsparkle/CopyADGroupMembers
• Summary: A PowerShell tool to copy group members from one AD group to another.

Toolbox #002: PrinterMonitor

• Blog: https://www.cloudsparkle.be/2020-04-06-Printmonitor/
• GitHub: https://github.com/Cloudsparkle/PrinterMonitor
• Summary: A PowerShell tool to monitor printers on a print server.

Toolbox #003: PSProfileCleaner

• Blog: https://www.cloudsparkle.be/2020-04-27-PSProfileCleaner/
• GitHub: https://github.com/Cloudsparkle/PSProfileCleaner
• Summary: Powershell script to clean user profile left-overs.

Toolbox #004: GetIISLogEndpoints

• Blog: https://www.cloudsparkle.be/2020-07-10-GetIISLogEndpoints/
• GitHub: https://github.com/Cloudsparkle/GetIISLogEndpoints
• Summary: Powershell – Gets all unique Endpoint IP’s from IIS Logfiles.

Toolbox #005: CountCTXAppUsers

• Blog: https://www.cloudsparkle.be/2020-09-14-CountCTXAppUsers/
• GitHub: https://github.com/Cloudsparkle/CountCTXAppUsers
• Summary: A PowerShell tool to Count user numbers per published resource on Citrix.

Toolbox #006: CleanADGroupMembers

• Blog: https://www.cloudsparkle.be/2020-09-30-CleanADGroupMembers/
• GitHub: https://github.com/Cloudsparkle/CleanADGroupMembers
• Summary: A PowerShell tool clean disabled accounts from an AD group, recursively if desired.

That’s it for now. Stay tuned for more and above all: stay safe.

Thank you

Bart Jacobs

CTA

Why? Because I recently needed to do precisely that: after having created a new AD Group, I needed it to have the same members as another AD Group. You can copy AD users, but not groups. Honestly, it was my initial thought I would be able to find this out there somewhere. I didn’t. Some scripts I found took a user account as the basis and copied “Member Of” to another user. That’s not what I needed. Other scripts were too “basic” like not offering support for an AD Forest with multiple domains.

So I decided to create my own. From the start, I decided I wanted something of a GUI. Nothing fancy, nothing custom. I have used Out-GridView before, and it would do the job perfectly this time around too.

The general idea was to make this publicly available, not just for my single use case. Hence the decision to put some checks in place, without taking it too far and over-complicate things for a simple copy script.

For example, the script checks if you selected the same AD group as source and destination.  It does not care if the destination AD group is empty or not. At the same time, it does not take AD Group Scopes into account and their specific membership constraints, etc. A simple Try-Catch to capture errors is just what I need for now.

Finally, Github is all the rage right now, so I thought I would give it a go.

Here is the link to the Repo:
https://github.com/Cloudsparkle/CopyADGroupMembers

I’ll try to get this uploaded to the PowerShellGallery as well.

Thanks!

Bart Jacobs
CTA

Let’s talk Citrix Cloud. More specifically, the Citrix Cloud Connector and its relationship with your network.

So, what is the Cloud Connector?
Docs.citrix.com tells us:

“Citrix Cloud Connector: Provides communication between the resources in the resource location and the Citrix Cloud.”

In other words, it’s a vital component. It’s the bridge between the resources your users do their work on, and the management plane for you as an admin, in the (Citrix) cloud.

Citrix recommends deploying two Cloud Connectors per resource location to provide high availability. What is a resource location you may ask?
Again, docs.citrix.com tells us:

“Resource locations contain the resources required to deliver cloud services to your subscribers.”
“Your resource location is wherever your resources reside, whether that’s a public or private cloud, a branch office, or a data center. “

So, let’s say you have a “classic” two datacenter setup, with actively used resources in both of them. They are interconnected and share a common Active Directory. Should you deploy this as one resource location or create a resource location for each datacenter? The latter would look something like this:

As with any Cloud-based service, don’t forget about the network. What if the Cloud Connector in datacenter A uses the Internet connection in datacenter B to connect to Citrix Cloud instead of the “local” connection? This would obviously add some latency to the connection.

Remember that the Cloud Connector can also be used as an HDX Proxy for your user sessions. To make matters more complicated, let’s assume that the same Cloud Connector in datacenter A connects the user with his workload in datacenter B. It will work, authentication will be just fine, and the session will connect.

As I was reminded of on Twitter (by Martyn Dews, @Yorkie71), starting with (CVADS and) VDA 7.18, there’s an option for a Direct connection from the VDA -> Citrix Cloud. In that scenario, it’s every single VDA that will need a path to the Citrix Cloud. Not just the Cloud Connectors anymore.  It’s using the Rendezvous protocol, as described in more detail in this blogpost on Citrix.Com: https://www.citrix.com/blogs/2020/03/10/ica-and-the-gateway-service-have-a-new-rendezvous/

It will all work, authentication will be just fine, and the sessions will connect. But is it ideal? Probably not, would be my guess. Why? It’s a working path, but not the ideal path. Take into consideration that Citrix manages the Cloud Connector. Which means that Citrix has the technological means to optimize the connection all the way to the Cloud Connector. After that, it’s basically just ICA/HDX traffic on your own network to your VDA endpoint. Deploy your Cloud Connectors and their connectivity to Citrix Cloud accordingly.

So, to wrap this up, what’s the key takeaway? In every Cloud deployment, Citrix Cloud or otherwise, always consider your network.

Thanks

Bart Jacobs
Citrix CTA

A series of events triggered this blog post. Or rather: my observations of Citrix Sales pitching Citrix Cloud to C-level execs.

Let’s start with the very basics: what is Citrix Cloud? And equally important what it isn’t.

Definition:
Citrix Cloud is a workspace management platform for IT administrators to design, deliver, and manage virtual desktops and applications and other services, such as file sharing, on any device.

In layman’s terms: the Citrix servers needed for the management of a Citrix environment, such as Delivery controllers, license servers, the SQL database, are provided to you by Citrix. Citrix takes care of the VMs running underneath, Citrix updates the platform and looks out for high availability of the platform. To put it very bluntly: Citrix provides you with a working, hosted version of Citrix Studio and then it’s up to you, the admin.

So, now that we’ve set the stage let’s discuss what Citrix Cloud is not. And this is the part where a lot of misconceptions start to show.

1) Is Citrix Cloud a managed service?
No. Citrix provides the management tools, not the management activities carried out by using those tools. Citrix will not publish any resources to any of your users.

2) Does Citrix Cloud host your apps and desktops?
No. This is about where your beloved users are doing their work, meaning: run those (pesky) apps. That “location” is completely up to you: public, private or hybrid cloud, or even just your good “old” on-premises resources. Any resource ties into Citrix Cloud through Citrix Cloud Connectors.

3) What about the “Service” naming then?
Citrix has a very rich history of name changes. XenApp Service is now Virtual Apps Service. This may set you on the wrong foot there. The “service” piece is not Citrix servicing your environment. It’s about Citrix providing/hosting the tools to you to maintain your environment from the cloud.

So, the question may arise: should you consider Citrix Cloud, and why?
It’s always a good idea to keep an open mindset and to be aware of all the possibilities out there. That’s a genuine challenge in today’s rapidly evolving world, I know.

The obvious answer is: it depends. A new company, starting with a green field deployment? Or an enterprise with custom, legacy apps? It all depends. Maybe I’ll turn the answer into another article someday.

Does Citrix Cloud have a “killer feature”?
Maybe it was a bit lacking in that department until recently with the Workspace App. Unification has always been a “thing” but presenting it “as a service” now is an entirely different ball game. Again, Citrix is providing you with the capabilities to create a unified Workspace. Citrix is not managing that workspace for you. But don’t dismiss that Workspace idea just yet. If anything, this may very well be your entry point to Citrix Cloud.

So, the future for Citrix Cloud looks all bright and shiny then?

Not so fast. Workspace (App) is evolving rapidly and will change. As will the entire platform. You need to be able to cope with that.

Just think about your endpoints for a second. They need to be able to connect. This means that you’ll have to keep them updated, just to keep up with the changing demands from Citrix Cloud. If sometime in the future Citrix requires a certain level of encryption, your endpoints need to be able to establish that encrypted connection.

There are other challenges too. Citrix requires that you purchase a minimum number of Cloud seats. This means that a lot of small businesses will not meet those numbers and have the option to pay too much or to look elsewhere. It’s not the first time I’ve hit on that topic.

Equally, even in a cloud world, there’s nothing like “seeing is believing”. Therefore, it’s a real shame there are no NFR or internal use licenses of Citrix Cloud for Partners. Partners that have built relationships with their customers will have to pay to show those customers their way to the cloud. Another missed chance, one that will drive adoption forward.

Thanks

Bart Jacobs

My answer is: yes, failures are bound to happen in the Cloud. Why? Because the cloud is designed and built by humans. And we all know humans are not perfect, present company included.

A “perfect” example of this is the latest Azure outage. While we still have to wait for the final RCA (Root Cause Analysis) a lot can (and has been already) written on that topic. I do recommend however to listen to the Microsoft Azure Podcast on the matter. It provides some fundamental human insight into the problem.

Yes, forces of nature did show that Mother Nature will always have the final word. But one part of the discussion included some internal Microsoft services still to be reliant on Azure ASM (aka Classic aka old school) technology. While Microsoft has been pushing everyone to ASR, they kept on using ASM themselves. And that has now failed. There’s no doubt that migrating from ASR to ASM was on some project sheet or to-do list. But they just never got around to it. Doesn’t that sound familiar? It should, and it’s called being human.

There’s also the matter of some storage account that wasn’t correctly configured and therefore not as highly available as everyone believed. Again, this sounds all too familiar, doesn’t it?

Still, I do find myself puzzled by the fact that the failure also impacted European users. But I’m not going to speculate any further, let’s wait and see in the final RCA in a few weeks.

I’ve heard and read comments on Microsoft’s poor design, their lack of In-Region availability zones, etc. The fact of the matter is, humans have designed the infrastructure of the competition too. So are they less prone to failure? Probably not, they just haven’t surfaced yet is a more likely answer.

But let’s take a moment to put this into perspective. The Cloud doesn’t present more failures compared to on-premises Enterprise IT. In fact, one might argue the opposite is even true. Cloud failures are likely to be more visible, but that doesn’t mean they happen more often.

What differentiates a good IT engineer from a great one? In my opinion, their ability to learn from their mistakes. Microsoft has been very open to the nature of the failure to date and has presented a clear vision to learn from their mistakes and adapt.

Some will say “too little, too late”. I’m not one of them. I do believe Microsoft does deserve some credit for their willingness to move forward and solve their issues. Those who think it can’t happen to them… that’s probably worth a future blog article.

Thanks

Bart Jacobs

That’s not the topic of this blog post, however. It’s not even a Citrix problem. But again, every Citrix admin will agree on this too; if the problem or issue is present on Citrix, then it’s a Citrix problem, period. So I won’t be writing on how to install and configure Office 365 applications on Citrix, it’s how those apps will connect to the magical entity, otherwise known as “The Cloud”.

Let’s take a look at Outlook. Outlook will always try to connect to outlook.office365.com. Now before Outlook can establish that connection, it needs to resolve that name into an IP address. Enter DNS. DNS is a vital part of today’s connected world. Microsoft will even tell you that Outlook uses a geolocation mechanism based on DNS to point you to the “best” entry point into their network. The latter is a crucial statement; you need the fastest connection to their network. Once there, they’ll take care of things for you.
Another important fact for you: “The Cloud” changes at an extraordinary pace. What’s relevant today, may be completely obsolete by tomorrow. In that light, it may or may not be true for you to see something like this when you do nslookup of outlook.office365.com.

First of all, if outlook.office365.com still resolves for you to something like outlook-emeawest3.office365.com, you’re in a bad place. More details on that below.

What can we actually learn from this? Microsoft DNS returns multiple IP addresses for that single DNS record. Why? Load distribution and high availability, what else? But if you look closer, there might be something off. When pinging those IP addresses individually, you might see a big difference in performance. Some will be a lot “faster” than others. And if ping can “see” that, you can be sure your users will “see” the difference too.

Why is this happening? Because those IP addresses are served from different Microsoft data centers around the world. And some are closer to you than others.

Remember I wrote something about being at a bad place some lines above?

Microsoft has been revamping the DNS resolution for some time now. How to find out? Outlook.office365.com should be resolving to a more generic outlook.ms-acdc.office.com by now. Microsoft keeps expanding its ACDC solution. And no, that’s not about music, but about AnyCast DNS Cafe. The reasoning is quite simple: Microsoft wants your users to connect to the Microsoft network as fast as possible. Once you’re on their network, you’re all set.

In general, ms-acdc returns a more consistent set of IP addresses and those would be “closer”, or in other words: faster for your users.

There is a moral to this story: you do have some influence of this DNS stuff. Choose your resolver/forwarder wisely. Some will work better than others. In my case, CloudFlare 1.1.1.1 servers returned IP addresses 10ms “faster” compared to the ones of our hosting/colo facility (even that’s a leading, global one).

Bottom line: DNS is essential to a successful Office 365 (or any cloud service really) implementation, on Citrix or otherwise. Your mileage will vary, so you’ll need to try and test for yourself and your users.

Thanks

Bart Jacobs

Actually, the idea of a follow-up story was already born within hours after publication.

So, without further ado, here we go.
Let’s start with one of the replies on Twitter, by Shaun Ritchie (@ShaunRitchie_UK):

“With Office 365 + most other apps are going SaaS I think a lot of SMBs evaluating if they need Citrix at all, regardless of licensing”

That’s an interesting statement. I think it’s safe to say that we, IT Pros in the EUC space that is, have been hearing for decades now that “Windows Apps are dead, it will all move to the Web/Cloud”.
The reality is however, Windows Apps are still very much alive and relevant today, and even new ones keep being developed and released.

Sure, for true greenfield applications, a web/cloud app is the way to go, but how many of those are out there? The majority of apps in any business have some form of legacy embedded in them. This can be legacy apps AND/OR legacy data. And to successfully transform a Windows/legacy app to a Cloud/Web App, that’s a completely different ballgame.

So with all those (Windows/legacy) apps out there, it all comes down to application delivery. It’s not about a VDI, it’s not about DaaS, it’s about Apps. And we live in a world where nothing really ever dies. There are still a considerable amount of companies using and developing COBOL applications today. They are even hiring! Let that sink in for a moment.

I do believe Cloud/web is part of the solution for the future, but I don’t believe it IS the solution.

Let’s throw an answer to this statement on Twitter in the mix by James Priest (@TheSmilingSE):

“That’s definitely true too, the SMB “SurfacePro” enabled user with O365 actually meets a lot of the old road warrior requirements now”

Again, Office 365 is mentioned. Again, very interesting indeed. Sure, O365 is/was a game changer for many companies. But why? Because it is “better” than their old local Exchange server?
I don’t think so. It’s not about being “better” it’s about being “more convenient”. For any company nowadays it has become extremely hard to run a local Exchange server. Just look at the price of Office 365, who can run a local Exchange for that money? I think you can answer that question for yourself.

While on the topic of money and therefore budgets… we really need to stop saying “cloud is cheap(er)”. It isn’t.

So in the end, for Cloud (Apps) to succeed, we need to make it more convenient for companies to make the switch. Users need their apps and data in those apps. We “just” need to deliver those apps the most convenient way, not the best way.

Thanks

Bart Jacobs

It’s time for another story, but not a technical story this time around.

I was actually inspired by recent events at Citrix, and those events being the round of layoffs all over the world. I’m not going to debate that move here, but at least it got me thinking.

Thinking about the past, present, and future reality. As part of the communication around the layoffs, an “Enterprise” focus was put forward for some products. And there’s no real doubt that the announced unwinding of Octoblu is part of that initiative too.

However, in recent conferences, Citrix announced a renewed interest in the SMB Market. In itself, a very healthy move. But what does Citrix see in an SMB company/customer? Actually, it depends on where you live really. What in the USA is marked an SMB, is in Europe another story. Those “American SMB” are quite often decent/large sized European companies. And that’s a shame because the real European SMBs are left out.

Historically, however, a lot of those SMBs have been loyal Citrix customers. I’m talking about the Benelux region in particular, where products like XenApp Fundamentals did fairly well. If not Fundamentals, a shop with 1 or 2 XenApp servers serving remote application access to a bunch of users was more or less standard in many SMB companies.

“Was” being the key word here. Because even while you can still do it, as Bas van Kaam pointed out in an article last year (http://www.basvankaam.com/2016/07/12/citrix-xenapp-single-machine-setup-cheap-fast-and-supported/), the “new” FMA architecture is mainly geared towards a multi-server setup with controller and workers separated. For scaling that’s a great move, but what if you don’t need that scaling?

Enter “The Cloud”.

With the rise of Office 365, SMBs are interested in the cloud. For Office 365, that just makes sense. It has become far too expensive to run Microsoft Exchange locally for a limited number of users. So why not apply the same principle to your Citrix setup? Well, there you go: Enter Citrix Cloud, or XenDesktop/XenApp Essentials. Problem solved, right?

Or Not?

Indeed, maybe not all. With the recent announcement of VMware Workspace One, one could start to argue Citrix Cloud is too expensive. But that’s only half of the story. All Citrix Cloud solutions come with a 25 user minimum. At the time of writing, I couldn’t find any information on the existence of such limits with VMware. It’s cheaper per user, I’ll give them that, but as I said, that is not the complete story probably.

So where does this leave the 10-15 user SMB, long-term Citrix XenApp shop? Upgrade to FMA locally? Pay for users you don’t need in the cloud? Neither option seems a great fit. With Microsoft pushing RDS once again, those long-term Citrix users could be tempted to switch.

Citrix shouldn’t be surprised the XenApp 6.5 install base is still quite large. Too large for their liking is my personal guess, why otherwise keep pushing the upgrade experience with every 7.x release? EOL for 6.5 is just around the corner remember, that should be reason enough.

If only…

Citrix would truly embrace the SMBs once again. They have the technology to do it. They are making Windows 10 VDI possible on Azure, they have the scalable Citrix Cloud platform,…

It gets even better. Citrix cloud includes the Remote PC feature, a true hidden gem.

So, as an SMB customer, you could have the complete story, all from Citrix cloud: secure access to business applications from anywhere AND access to corporate desktops at the same time. Application delivery is why most of them chose Citrix in the first place. Add the Remote PC feature to simplify SMB IT life, … In the future, use Azure AD to bind it all together including Office 365.

So… why is that still a dream today, and the only thing standing in its way of becoming a reality is a license policy that tells otherwise. It’s a shame.

Thanks for listening

Bart Jacobs (the views expressed here are mine and not necessarily Webster’s)

Originally, it wasn’t my plan to have a Part 2 in the first place. When I started writing the script, it was my goal to include all checks into a single script.
I rather quickly abandoned that idea because the script became too bloated and slow. At the time, some checks that are now part of Part 2, were based on WMI queries. We all know WMI, but not for it’s speed, right?

So I decided to keep it simple, and at least start somewhere instead of keep on trying. The result is Part 1.
But I couldn’t just pass up on my original idea either.

So I decided to take the same framework (with loop, offset timer, and other parameters) and add the other tests. And at the same time trying to avoid the usage of WMI queries as much as possible.
Tests I included:

• CPU usage
• Memory Usage
• Disk Usage
• Disk queue length

In the end, I was forced to use a single WMI query, and that was needed to determine the amount of memory for a machine:

$MEMtotal = ((get-wmiobject -Computername $server -class “win32_physicalmemory” -namespace “root\CIMV2”).Capacity)

This proved to be a challenge, because that query doesn’t return a single value, but returns the value for each memory module in an array.

But what about VM’s? They have “virtual” memory modules. One per 16Gb of memory (as far as I could check). So as long as your VM has less than 16Gb, a single value is returned. When the VM has more, multiple values are returned. So I needed to find a way to cope with these different possibilities.

This is the solution I found:

$sum = $MEMtotal -join ‘+’
$MEMsum = Invoke-Expression $sum

The first line creates an expression with all array values and adds a “+” sign in between them.
The second one “executes” that expression, effectively returning the sum of all (virtual) memory banks.

The end result is again saved as an HTML file, and I integrated that one into another IIS page using an iframe.

The end result looks something like this:

I didn’t include any logging in this 1.0 version, I wanted to assess the value of these readings first.

You can always find the most current files by going to https://www.carlwebster.com/where-to-get-copies-of-the-documentation-scripts/ and looking in the Bart Jacobs’ Toolbox section.

Stay tuned for more!

Thanks

Bart Jacobs

More specifically, monitoring XenApp with Powershell.

Since many of my customers are still running 6.5 (yeah, I know), I’m focussing on that version first.
And I know that lately, others have been releasing monitoring scripts and even entire frameworks.

Yet, I still wanted to put my work out there, not because I think my scripts are better, but to give you another option, or another source of inspiration.

In this first blog post, I’m presenting my XenApp dashboard script.  The script was based on the Farm Health Report by Jason Poyner, over at https://deptive.co.nz/xenapp-farm-health-report/. I reached out to Jason at one point, and he was ok for me to base my script on his script and even publish it. But he certainly deserves some credit too.

Basically, it comes down to this. The original script is a one-off, meaning, the script produces an outcome and that outcome is mailed or otherwise made available. But that’s it, once the output is there, the script is done.

I wanted something more like a dashboard. So I built a loop around the script and scheduling at server boot. So the script would continuously generate output. Output, in this case, an HTML file, that I would integrate into another website using your everyday iframe.

But that wasn’t the full solution because I wanted data to refresh faster. Since I couldn’t find a way to run through the server checks faster, I worked on the only alternative I could think of: the looping of the script. So I introduced an offset parameter, allowing me to start the script at a given time (sleep) interval. And I would schedule multiple script launches at server boot, each with their won offset. So let’s say if it takes 60 seconds on average to check all servers, I would schedule a script with offset 0 and 30. So when the first script finishes after 60 seconds, the second one will finish approximately 30 seconds later.

This has worked really well for me, producing output like:

As you all know,  using server silos is a popular implementation of XenApp 6.5. So that’s the final parameter I added. You still need to include the logic for the silo naming, however. For example, you could include all servers starting with “BE” in a silo etc.

Versions 1.0 and 1.1 of the script were never published out in the open, but I’ll tell my story on them anyway. They are about logging to CSV. In 1.0, there was no logging, only a “real-time” dashboard. In version 1.1, a CSV per server was generated containing date/time, the number of active sessions and the server load. In version 1.2, the version I’m “releasing” today, at every offset 0, I would add data of servers to a “datacenter CSV” file, a file containing all data of the data center. Those CSV’s can be used to drive PowerBI or Excel PowerPivot stuff.

Again, I’m not trying to convince you my script is any better than those already out there. It’s not. I only hope that it would give you some food for thought and even some inspiration.

You can always find the most current files by going to https://www.carlwebster.com/where-to-get-copies-of-the-documentation-scripts/ and looking in the Bart Jacobs’ Toolbox section.

Stay tuned for more!

Thanks

Bart Jacobs

This tool is even simpler than the print driver stuff in my previous article.

But again I hope this addresses a real need out there, it has done so for me.

Everyone that has used Microsoft Remote Assistance (or some other tools) probably remembers asking the user on the other side what the name of the server/computer he or she is working on.

Sure you can force the users to use a wallpaper generated by bginfo.

Sure you can write and provide instructions to the user on how to find that information…but we all know they will keep asking you over and over again, right?

But actually, you want users to be able to provide that information fast and simple, and only have to tell them once, no matter what OS they are using.

I looked around for some tools out there, but most of them were either too complicated or just not working on an RDS/Citrix environment.

So I stumbled on an AutoIT script that was going in the right direction. I used it as a basis for mine, created an Exe and deployed the tool to end-users, and have it launched at startup.

So now every user has the same icon in their notification area and when hovering over it the name of their machine will appear.

You can download a zip file with the compiled exe and the AutoIT source code.

You can always find the most current files by going to https://www.carlwebster.com/where-to-get-copies-of-the-documentation-scripts/ and looking in the Bart Jacobs’ Toolbox section.

Stay tuned for more!

Thanks

Bart Jacobs

Sure, XenApp 6.5 has had a driver replication feature for a long time, but that isn’t without flaws… So I wanted something different, something where I was in control.

I’ve become a fan of Admin Arsenal’s PDQ Deploy some time ago, so I designed my solution with that in mind. It should work with other software deployment tools and even manually it would all just work. In case this is the first time you’ve heard about PDQ Deploy, I strongly encourage you to have a look at www.adminarsenal.com.

I needed a way to install the print driver on remote machines, not map a printer, not creating a printer port, … just keep it simple: install the print driver, nothing else.

The scenario I had in mind was quite clear. Every print driver comes with an INF file with driver descriptions etc and every Windows version since Windows 2000 has a built-in utility called printui which can be used to install printers, drivers and ports. The printui tool needs the INF file and the exact driver name as stated in that file to work. So my idea had to consist of 2 parts:

1. Select the right printer model out of the INF file
2. Parse that INF file together with that printer model to printui, on the target machine.

So I started creating PowerShell scripts for both parts. I’m not a PowerShell guru by any means, so if the code doesn’t look as slick or clean as it could, that’s on me and my coding “skills”.

The simple scenario grew and turned into this:

1. Launch script “PrintModelSelector”.
2. This script will prompt for the INF file to process.
3. It will present a list of Printer Models it finds and prompts to select one.
4. The name of the Printer Model is saved together with the INF file name into a CSV file in the same directory as the INF file (so: where the driver is really).
5. The second script “PrintDriverDeploy” will read that CSV file and parse info to printui, actually installing the print driver.

INF file processing turned out to be a hard one, and my solution works but is not perfect. For those situations, the download will include a sample PrintDriverDeploy script and CSV file you can adapt for those cases it doesn’t work. I’ve tested with quite a number of INF files, and recent ones all worked as expected. Some old exotic ones didn’t but that can be fixed manually.

The final stage of my “project” was to create the PrintDriverDeploy script at runtime. What I mean by this is that the first script creates not only the CSV file, but also the script to parse that file, both in the same location as the selected INF file.

Going back to my PDQ Deploy story, that’s the script I would be deploying in the Package.

Tip: make sure to select the “Include Entire Directory” option, as you’ll need to push all driver files to the target device.

As I’m running the free version of PDQ Deploy, I can say that it works with any edition.

I couldn’t resist taking it one step further… A few weeks back I saw the tweet from Andreas Nick about a free, built-in tool to convert PowerShell files into EXE’s.

You can find the link to his tweet and YouTube video here. So I used this procedure to convert the first script into an EXE, so it can be run without any PowerShell limitations.

The download includes this EXE, the PowerShell version, the sample CSV and Deployment PowerShell too.

You can always find the most current files by going to https://www.carlwebster.com/where-to-get-copies-of-the-documentation-scripts/ and looking in the Bart Jacobs’ Toolbox section.

I hope you find this useful and I am really looking forward to your feedback.

Thanks

Bart Jacobs

Anyone that has done some XenServer updates/upgrades surely has come across the “ghosted nics” issue before. I’m certainly not alone since CTP Alexander Ervik Johnsen also wrote a little something on his blog the other day. You can read about his solution here.

As you might have guessed, Ghost or Phantom NICs are a bad thing. The solution sounds simple enough: get rid of them. From a technical perspective, it’s not a difficult thing to do. As Alexander Ervik Johnsen mentioned, it’s a matter of following these steps:

1. Log in as a local admin account (TIP: make sure you know this one BEFORE you start upgrading)
2. Open a command prompt
3. Issue the command “set devmgr_show_nonpresent_devices=1”
4. Launch Device Manager by typing devmgmt.msc in the same command prompt session (so the device manager session “sees” the environment variable)
5. In Device Manager, select View -> Show hidden devices
6. Now the Ghosted NIC’s should be visible, and you should be able to uninstall them just by right-clicking them and selecting uninstall

It’s a quite straightforward procedure to follow, but it can become a very tedious job if you need to go through these for a high number of VM’s.

And there’s more to it. From time to time, Device Manager does not seem to respond to the uninstall command. You click uninstall, you do a refresh, and the device is still there. Issuing multiple uninstall commands won’t help you either.

So then there is the option to dive into the Registry and carve out the Ghost device by hand. It can be done, but it will take time and is not without any risk.

The solution? Enter a marvelous tool I (re)discovered recently: GhostBuster (by wvd_vegt, https://bitbucket.org/wvd-vegt/ghostbuster/src/master/). It scans for ghosted devices, shows them in a nice GUI, so you can select the Ghosted NIC by selecting “Add Device”.

When selected, you hit the Remove Ghosts button

And you’re done.

Ghostbuster even comes in a portable format, so there’s no need to install it every time.

So, to make my life a bit easier, I created a small ISO file that I can mount on a VM. That ISO contains a couple of things:

• start.cmd -> sets the devmgr environment variable and starts Device manager with “View Hidden” already enabled
• the MMC used by start.cmd, which is good old Device Manager with “View Hidden” enabled.
• the portable version of Ghostbuster

I’ve thought about automating it some more, like using GhostBuster to clean stuff automatically. The biggest issue is that in my environment, the number of ghosted nics is not always the same, and it’s not always the “Realtek” either, I’ve seen cases where I have the Realtek nic, and 3 ghosted Xenserver NICs together. In that type of situation, I’d like to control things myself because this usually means something else is also very much messed up with that VM.

Maybe I’ll do the automation part in the future, but I use the ISO as-is for now. If you like it too, you can find it in the Downloads section.

You can always find the most current files by going to https://www.carlwebster.com/where-to-get-copies-of-the-documentation-scripts/ and looking in the Bart Jacobs’ Toolbox section.

Thanks

Bart Jacobs

But sometimes, even in a virtual world, physical problems can be a real pain.

Recently I was involved in upgrading/migrating an outdated XenServer 6.0 setup, running on HP BL460c Gen7 and Gen8.

The Gen8 boxes went fine, and the customer was really impressed with the performance of XenServer 6.5 SP1.

The Gen7 boxes were quite a different story. Yes, I’m ware they are not on the official HCL First of all, as any good admin should do, I was upgrading firmware and BIOS when the server was off duty anyway.

The first server I updated, XenServer didn’t detect the Emulex 10Gb ports anymore. But on the second one, it did… The third one was a failure again.

Then I noticed something wrong on the boot screen:

I used the HP Firmware CD to update everything, and although the version v10.5.155.0 is the correct one, it did’nt quite seem to work. Also on ILO, the config looked very wrong.

So… why? Well it seems HP has had a long history of firmware misbehavior on the G7 series, and somewhere along the line people suggested to reflash the firmware again with the same version.

That’s not possible with the HP Firmware CD, so I downloaded the Emulex firmware CD from the HP site. That did come labeled as v10.5.160.0… but installed v10.5.155.0 anyway.

After that “update”, no more strange screen at boot and… XenServer recognized the NIC’s just fine once again.

So I know they are becoming old, those G7’s, but maybe this will help someone facing the same or similar issues.

Thanks

Bart Jacobs

This made me remember an issue I had dealt with earlier, very similar to the one Carl was facing.

Mine presented itself on XenApp 6.5 on Windows 2008R2 though. I wasn’t using a published desktop either, but Published Apps. When inside a published app, a user tried to open a URL, nothing would appear to happen for that user, it seems IE would start and close again. In another occasion the user was prompted over and over again for his credentials when accessing a web service displaying a PDF file that was stored on that webserver.

In my case, it was pretty consistent too. Those specific users ran into the problem every single time, every session on every available server. Other users on the same servers worked perfectly.

The solution? Those users didn’t have “Active Setup” in their profiles. Active Setup? Yes, that is wat Carl is referencing to in his article. Everyone should have seen this screen at a given time:

So for some reason the affected users didn’t have working “Active Setup” settings in their profile. My solution at that time was them have run 2 scripts containing these lines of code:

Script 1:

"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP

C:\Windows\System32\ie4uinit.exe –UserIconConfig

%SystemRoot%\system32\unregmp2.exe /ShowWMP

"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iesetup.dll",IEHardenUser

"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iesetup.dll",IEHardenAdmin

C:\Windows\system32\Rundll32.exe C:\Windows\system32\mscories.dll,Install

C:\Windows\System32\ie4uinit.exe –BaseSettings

regsvr32.exe /s /n /i:U shell32.dll

%SystemRoot%\system32\unregmp2.exe /FirstLogon /Shortcuts /RegBrowsers /ResetMUI

"%ProgramFiles%\Windows Mail\WinMail.exe" OCInstallUserConfigOE

%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

Script 2:

"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iedkcs32.dll",BrandIEActiveSetup SIGNUP

C:\Windows\SysWOW64\ie4uinit.exe –UserIconConfig

"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iesetup.dll",IEHardenUser

"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iesetup.dll",IEHardenAdmin

C:\Windows\SysWOW64\Rundll32.exe C:\Windows\SysWOW64\mscories.dll,Install

C:\Windows\SysWOW64\ie4uinit.exe –BaseSettings

regsvr32.exe /s /n /i:U shell32.dll

"%ProgramFiles(x86)%\Windows Mail\WinMail.exe" OCInstallUserConfigOE

Looks familar? It should, because it’s (more or less) the same script as Carl described.

In short, if IE is behaving strangly, or better said: not working as expected -> make sure to look at Active Setup. This not only applies to XenApp/Desktop 7.x on Windows 2012R2, but also to “good old” XenApp 6.5 on Windows 2008R2.

Bart Jacobs

A few years back I already wrote about picadm.sys issues: https://www.carlwebster.com/the-curious-case-of-the-slow-file-transfer/

Citrix has been updating picadm.sys numerous times since then, and also did in the latest release: HRP06. And before that in XA650R05W2K8R2X64015 too.

However, it seems that XA650R05W2K8R2X64015 introduced a new(?) bug, that was also present in HRP06. That’s actually quite logical as HRP06 supersedes XA650R05W2K8R2X64015, so XA650R05W2K8R2X64015 is included in HRP06.

Just try this PowerShell oneliner in a XenApp session with client drives enabled and see for yourself:

get-process | out-file -filepath “\\client\c$\temp\proclist3.txt” -Append

Obviously, you need to have a c:\temp folder for this to work.

The first time you run this, a file will be created.

When running this a second the time you will find that the file on your c:\temp is not updated. Most of the time it will also throw an error: Out-File : The handle is invalid.

The HRP06 version throws an error but XA650R05W2K8R2X64015 just does “nothing”.

Uninstalling XA650R05W2K8R2X64015 resolves the problem, I have not yet uninstalled HRP06 yet.

So… what’s next? I didn’t recommend installing HRP06 yet anyway, you should wait for XA650R06W2K8R2X64001, which contains the fix for rpm.dll crashes.

But in the meantime, I’ve opend yet another Citrix Support Case on picadm.sys. Let’s hope it gets resolved faster now…

Thanks

Bart Jacobs

I have been looking at this announcement with a kind of special interest, my first curious case, which you can read here.

And what did I see in the presentation?

What does Citrix mean by this? “Some customers have reported issues in Client Drive Mapping related performance, and this is vastly improved in FP2.”

Way to go, Citrix! But wait a minute… Citrix just turned a bugfix into a feature…what’s up with that?

In the end, let us all hope that we can finally resolve the issue at stake here. It’s been too long already.