Does anyone else in here use powershell as a sysadmin? If you do, do you also feel the agitation and drive to want to throw yourself down a stair case face first through frustration?

I hit a wall a couple of weeks ago due to the deprecation of msonline and with this believed it would be good to move to PS7. What I didn't realise is how much of an absolute jar of jam and mustard mix Powershell is. Core, Desktop, modules and clashing assemblies. Trying to combine ps7 core with AD, AzureAD and having to use Graph for license management - urgh!

I just spent two days writing up an amazing script with functions and arrays to load modules, connect to Entra, get licensing info with nice math, turn that in to a menu, create local AD user and sync, license in EntraID, mailbox enable and sync location, the works.

Then, something changed in a module update. Locally in the OneDrive I had 2.6.1 of graph users and Auth, that was playing well with AzureAD in core, but OS had 2.7.0 of graph. I cleared out my modules and it's broken everything, even on reinstallation.

How in the bloody Hell is Powershell ever supposed to be used and stable when module inconsistencies exist everywhere? I pulled down AzureAD again to find it no longer connects in PowerShell 7 core due to assembly version issues. I use the switch to use Windows Powershell for the AzureAD connection to then have that break the licensing math that was working in a function.

Sigh.

I'm coming from Bash on Linux where shit just works. It works for YEARS! Very few times in my almost 30 year career have I had Bash just decide it doesn't want to work and when it does, it's documented. Powershell does not seem to make sense or be documented well.

Anyway. Rant over. Back to working out what module I need fixed at an EXACT version to make it all work again and to hope MS don't randomly deprecate it again.

EDIT and SOLVED!
I shouldn't even need to update this but after spending a lot of time debugging, it turns out that you cannot call microsoft.graph.users and microsoft.graph.users.actions as they will clash, even though they are part of the same package, you'll get assembly issues. The fix - install the whole MICROSOFT.GRAPH module, all 10k parts of it, but DO NOT IMPORT IT. Now you can import-module microsoft.graph.users and the parts from .actions will also be available without loading. I don't understand why, I'm actually past caring. I'm hoping someone else scouring the internet and hitting the same wall may stumble on this and it'll help them out. Hell, I may even blog about it. Thanks for listening to my misery.

Firstly, I apologise for the rant. I guess this is a meek follow-up to my submission earlier in ~comp, questioning how to deploy Docker into production. Since then, I haven't been able to dedicate much time to solving any of the issues I've outlined in that thread, but what I will say is that docker has caused me nothing but pain, and I have realised zero benefits from attempting to utilise it. Right from the start, the syntax for docker, docker-compose, and Dockerfiles is confusing and full of edge cases which no one explains to you in the hype of actually discussing it:

• These 'images' you build grow to insane sizes unless you carefully construct and regiment your RUN, COPY, and other commands.
• Docker complains to you about leaving empty lines in multi-line RUN commands (which is itself, as I see it, basically a hack to get around something called a "layer limit"), even if it contains a comment (which is not an empty line) and does not provide a friendly explanation on how to solve this issue.
• There's basically no good distinction between bind mounts and volumes, and the syntax is even more confusing: declaring a volumes entry in a docker-compose.yml? You have no good idea if you're creating a volume or a bindmount.
• Tutorials & documentation tends to either assume you're a power user who knows this sort of thing, or are so trivial they don't accurately represent a real-world solution, and are therefore basically useless.

I've suffered endless permissions issues trying to run portions of my application, such as being unable to write to log files, or do trivial things like clearing a cache—that I have tried a dozen different ways of fixing with zero success.

Then, when I run some things from within the docker container, such as tests, they can take an excruciatingly long time to run—only then did I discover that this is yet another docker issue. The whole point of docker is to abstract away the host OS and containerise things and it can't even do that.

So now I'm regenerating and rebuilding images and containers every 5 minutes trying to find a configuration that appears to work with the slow and complicated syntax of docker rm $(docker ps -aq) -f followed by docker rmi $(docker images -q) followed by docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d, followed by docker container exec -it php sh.

Docker-sync, kubernetes, docker-compose, images, containers. It's legitimately too much. I'm not a dev-ops or infrastructure guy. I just want to write code and have my app work. I don't have the money to employ anyone to solve this for me (I'm not even employing myself yet).

I guess you can say I've learnt my lesson. I'm sticking to git and a simple VPS for future endeavours. I don't know how you folks who manage to hype docker do it, and I don't know what I'm doing wrong, but Docker doesn't like me, and I don't like it.

Each element in the report has an 'Evaluation Time'. The catch, as I'm beginning to realise, is that only those rendered 'Now' actually have any ability to expand or collapse the bands within the report. i.e. it makes an initial pass (evaluation time 'Now') and figures out the sizes, and then goes back and recalculates the content (but not the size) of the stuff.
Which is great, except that I'm trying to print something (which should disappear when empty) from a subreport, which only works if it's deferred. Guess I'll have to accept that that band can't be collapsed when empty. It's OK, I'll just redesign my report then.

/rant over.