Microsoft PowerShell | David's Blog

Microsoft is bad at software

These past few years at work, we moved from Novell to Microsoft. It has definitely been a move for the worse.

Novell	Feature -poor	High quality	Low expense	Security: low profile
Microsoft	Feature -rich	Low quality	High expense	Security: target rich environment

Comparison between Novell and Microsoft

I’m just going to say that I dearly love (not):

That Exchange Online has a new command New-DistributionGroup -RoomList which cannot be seen in admin.exchange.microsoft.com. New feature? Microsoft says Yay! Actually making it available to end user administrators? Ain’t no-one got time for that. Certainly this has been vetted thoroughly for security, too.
Exchange Online –> Mail Flow –> Connectors –> Status set to “Off” does nothing. Mail still kept going to the partner, a week later.
Set-Place command for adding the rooms to the RoomList – error! No worky! How to fix? Reboot the PC I was trying to run the PowerShell script on. Now it works. This is just so impressive. Have you tried turning it off and back on again? It’s two decades into the 21st Centrury – shouldn’t someone up there be ashamed?
User asks for help, so I get delegate rights to her mailbox. The delegates rights are present (I run a script to check) but never did her mailbox populate so I could see what was going on in her mailbox. I deleted my own OST cache file just to make sure it wasn’t my machine. Ultimately, I had to use Outlook Web Access to see her mailbox.
1. Every week we get multiple help desk tickets about folders not populating or visible for delegates.
Exchange search is awful. Admittedly, I am coming from a GroupWise experience where search was great. But as important as search is, I would have thought that Microsoft could at least have pulled off “competent” – nope. I particularly like (not) that OWA has a drop-down for “search all folders” but the search only searches the current folder. What a bunch a maroons.

These were all in the last three days. I’ve seen nothing but this sort of low quality software for so many months now. Don’t even get me started on SharePoint.

Don’t forget – Microsoft will break your stuff if you do business with a competitor.

Dear Lord I wish I could retire tomorrow.

Microsoft is not good at software

“No shit, Sherlock”

All I’m going to complain about at the moment is Task Scheduler, and how I can run a PowerShell script if the script is on the local C: drive, but if the script is on my H: drive (which is on the network) then it’s no longer PowerShell, it must be ImpotentShell and should thus fail.

Apparently networks scare Microsoft?

Task Scheduler will attempt to launch it, with the target being powershell -File H:\blah\foo.ps1

But that run of the task will fail with the result code 0xFFFD0000

The only change I made to the Task Scheduler was to change the target path from -File H:\blah\foo.ps1 to C:\blah\foo.ps1. Now the script runs, where it failed before.

I find the whole attitude of “well, the network is so fragile that we are going to fail when we to try” moronic. The freaking machine this script on is a VM (a file) loading across the network you dolts.

But no…. We can’t have a PowerShell script on a network share. Network shares were invented 39 years ago – there’s no way that Windows can rely on tech that bleeding edge and unstable. So now I have to build stupid shit file synchronizing routines to keep changes made in the official repository up to date with the stupid copy on the stupid C: drive.

Please, Microsoft, keep working on Windows 11. Moving the start menu to the center of the screen is so important.

Also: why on the Lord’s Green Earth is the Task Scheduler All Running Tasks dialog box a fixed width? Wasn’t Windows 3 like, twenty years ago?

Man, I wish I could retire from this job.

Microsoft fouled up when they got rid of gallery.technet.microsoft.com

In the real world, people like to find solutions and then link to the solution as a form of documentation. It is a way of being helpful. I can feel good about myself if I help you out (or at least I’m trying to help you out). The result is that there tend to be a lot of forum discussions and blog posts that have a link to a gallery.technet.microsoft.com script that solves the problem.

As solutions go, gallery.technet.microsoft.com was a great idea. People write a script, that script works, so the author donates it to world at large by publishing it (free of charge and disclaiming all complaints about damage). Microsoft benefited because if you knew nothing else, you knew to go search there for possible help. If I’m trying to solve a problem, and I find the solution on gallery.technet.microsoft.com, then I’m helping if I tell people “here was my problem, and I found the solution: foobarbaz at gallery.technet.microsoft.com”

Unfortunately for us, someone at Microsoft felt the need to push the world into complying with their grandiose idea: “Let’s get rid of Technet and replace it with docs.microsoft.com !”

This was a terrible idea.

And no-one at Microsoft was grown-up enough to stop it.

So now, the world wide web is littered with broken links to solutions that used to be helpful, but now go to https://docs.microsoft.com/en-us/samples/browse/?redirectedfrom=SomethingThatUsedToBeGreatButWeKilledIt

I don’t know what they were thinking, but it was probably someone wanting to pridefully change the world to comply with the way they thought the world ought to be. All they really did is break a previously good thing.

Wow Perl PAR::Packer sucks

I presented a problem to my boss, where I need to let about 30 desktop technicians run some code I’ve written. My boss said when he is in that position, he writes it in PowerShell, and uses PS2EXE. This is good idea. I found that in the Perl world, the same idea is in PAR::Packer.

A super simple script, running on my Linux box, takes less than one second to run. Open up an SQLite database, fetch all 20 records, sort them, print them. Simple. Less than one second.

The Windows .exe version takes 19 seconds.

Every. single. run.

There is no way that the on-call technicians who have to run the scripts I’m writing are going to be happy with that. And it would make me feel bad, inflicting that sort of this-is-time-of-my-life-that-I-am-not-getting-back on some poor soul who got a call at two in the morning, to deal with whomever for whatever.

Normally, on Windows, I used WinBatch. Did so for 20 years. But alas, WinBatch was always a for-pay product, and eventually hobbyists wrote AutoHotKey (or was it Auto-It?) (for free) to do everything WinBatch does. Also, the real goal was to take my Perl scripts that use REST to get and put JSON or XML at a web service. WinBatch has lots of old extenders, but rarely any new ones. I don’t know of a REST extender for WinBatch. I don’t know of anything in WinBatch that does what DBI does in the Perl world. The WinBatch answer is to install MS Access (or whatever) and use COM to drive the actual database client. Avoiding installing software is part of the goal here. I need something That Just Works.

And preferably works in a second or two; not twenty.

I’ve got REST modules written in Perl. I’ve gotten far enough in my Perl skills to put standardized code in modules, and then use those modules. But that meant putting modifying the search environment for finding modules. Guess what doesn’t work with PAR::Packer?

Okay, crap, I can move all my modules into the root directory where my scripts are. This is stupid, but I’ll do it.

And then I find that the execution speed of even a simple script is terrible.

Searching for a solution, of course the answer is “You’re doing Perl wrong, if you don’t want to install an entire development environment on every workstation”.

Well, thanks for nothing. Apparently I need to give up Perl and start learning PowerShell. PowerShell does rather look like Perl, so maybe it won’t be too terrible of a transition.