mpw222

PowerShell is terribly slow compared to basically anything, but the slow bit here is probably the I/O. Each Add-Content call is a opening appending and flushing to the file, in the inner loop. The fact that Foreach-Object is vastly slower than the foreach keyword and that Add-Content itself is much slower than System.IO doesn't help, but I suspect this is basically I/O and the fact that this type of file access pattern tends to drive AV software crazy. Using a StreamWriter and getting the associated buffering would probably be a lot faster.

My 2 cents having gotten about 10 bugs in Microsoft products (mostly Windows and Office, some server, some client, some kernel mode, some user mode):

You basically have to pay for Premier Support or find a way to get in touch with a developer out-of-band to get anything fixed. Even going through Premier is a brutal process, as a consumer, try to find a human at Microsoft or just give up. Even if you do pay the ransom for fancy support, you're still way better off trying to find an alternate way to contact someone on the team. Write a blog post, tweet at someone, post on HN or Reddit, whatever.

If you do go through Premier, hope that your bug repros every time with a procedure that takes no more than 5 numbered steps. Anything beyond that, give up. Never ask for advice or assume common sense or anything with any room for interpretation.

Hope that your bug is in something that is about 1 year old. Any newer and support has never touched it and is surprised anyone in the real world uses it. Much older and they won't risk a change.

This has gotten better recently, but be prepared to fill out a lot of questionnaires about why some data corruption bug or memory leak is a problem for your business. These will be insane in context. At one point I had to write 8 pages about why Task Scheduler (their cron, more or less) should run tasks on the defined schedule, as opposed to not running them.

Hope that your issue is in a core-ish server product. The support teams for AD, Exchange and SQL are significantly better than anything client side. Just as long as it's one of these older established products and not something new, if it's new, support won't know what it is.

There are incredibly competent and helpful people in Microsoft's support org. Like fix your bug in a 15 minute phone call after a hundred hour case, cut you a private build and ask you to confirm the fix - competent. I'd estimate there are about 4 of these people in that entire support org, and you don't get to talk to them until you've invested a month or two in escalations and repros.

Oh and answers.microsoft.com is an anti-service. It's like experts exchange in the dark times, only worse. There is no useful information there and it serves only to add noise to your search results.

Writing a robust, idiomatic PowerShell function of any complexity is deceptively challenging, and the background required to do it correctly is almost all unique to PowerShell. PS is a weird amalgamation of C#, Bash, Perl, VB and cmd-isms that ends up being incredibly confusing to basically everyone.

Try getting an experienced C# developer to write a PS function that:

- Initializes an IDisposable resource and deterministically disposes of it when the function terminates (successfully, with an error, or due to ctrl+C). - Honors the caller's $ErrorActionPreference/-ErrorAction. - Understands that catches won't catch "non-terminating" errors. - Throws errors without trashing the ErrorRecord so that the caller gets a meaningful stacktrace. - Copes with the difference between process working directory and PS working directory if a .NET method and a relative path are involved. - Doesn't blow up on a square bracket because someone didn't realize they needed -LiteralPath. - Doesn't accidentally write an unintended object to the pipeline. - Does something reasonable with pipeline input. - Doesn't get tripped up by type coercion magic - $a = @(); $a -eq $null - Uses multiple ParameterSets without creating ambiguity problems. - Doesn't get tripped up by PS silently swallowing exceptions thrown by property getters. - Uses some appropriate subset of language features and modules available across different versions of the OS and WMF. The OS based limitations are understandable. The hard dependencies that Microsoft's own products have on specific PS versions are not. - Is not super-slow.

It's not impossible, but it sure is hard (and takes a ton of boilerplate), and there aren't many resources out there to teach you how. It's all quick and dirty "how to do X" recipes for sysadmins that don't care about more than what they need to paste into a console.

To be clear, I actually mostly like PS I'm just trying to express a set of pain points here.