Managing Windows Local Users with Net User
-
@JaredBusch said in Managing Windows Local Users with Net User:
FFS the entire point of the post is to not use net user. WTF
Actually it was. I think you are thinking this is the PowerShell one.
-
@scottalanmiller said in Managing Windows Local Users with Net User:
@JaredBusch said in Managing Windows Local Users with Net User:
FFS the entire point of the post is to not use net user. WTF
Actually it was. I think you are thinking this is the PowerShell one.
Hahah! Foruming and driving!
-
@JaredBusch Oh goodness, too funny
-
@JaredBusch said in Managing Windows Local Users with Net User:
@travisdh1 said in Managing Windows Local Users with Net User:
@scottalanmiller Change user password interactively
net user sally *FFS the entire point of the post is to not use
net user. WTFI needed to upvote this up
sums up how you feel about this command -
@travisdh1 said in Managing Windows Local Users with Net User:
@scottalanmiller Change user password interactively
net user sally *I totally thought it said salty until I seen your comment.
-
@Obsolesce said in Managing Windows Local Users with Net User:
@travisdh1 said in Managing Windows Local Users with Net User:
@scottalanmiller Change user password interactively
net user sally *I totally thought it said salty until I seen your comment.
I need to use Salty as my go to sample user.
-
@scottalanmiller said in Managing Windows Local Users with Net User:
@JaredBusch said in Managing Windows Local Users with Net User:
FFS the entire point of the post is to not use net user. WTF
Actually it was. I think you are thinking this is the PowerShell one.
PowerShell wins hands down...
Each of those commands can be done with three letters plus the username, no switches needed.
-
@Obsolesce said in Managing Windows Local Users with Net User:
PowerShell wins hands down...
Not from looking at your argument. It has some minor advantages, and some minor disadvantages and the one massive "can't be ignored" disadvantage of being ridiculously obtuse and non-obvious. Which, alone, is the killer problem.
-
@Obsolesce said in Managing Windows Local Users with Net User:
Each of those commands can be done with three letters plus the username, no switches needed.
Herein lies the problem... you are defining "easy of use" by...
- The number of characters in an alias.
- An alias.
I can make a one letter alias in BASH. Does that change the complexity of a task? Obviously not. But this is what you have to use to make PowerShell seem rational.
-
For example, want to shorted "useradd"? Just make a "ua" alias. Now it is two letters. But harder to remember.
useradd isn't hard to type. It's already perfectly short. The problem in PowerShell isn't that the commands are long (although they often are unreasonably long), but that they are non-obvious and there are way too many for too few tasks.
Using aliases makes that situation worse, not better. The PS ecosystem is a quagmire of impossible to remember, non-obvious commands. No matter how "short" you make them, you make the entire ecosystem harder to remember and to remember accurately. Sure you can look them up to try to make a point, but in the real world, normal admins don't use aliases for every command, because it's too much to even possibly remember. It's hard enough to remember most of the main commands.
That you feel PowerShell is so awful, that there needs to be aliases to make it reasonable makes a really strong statement. That you see PS in that way, is kind of the point. In the Linux world, we don't feel the need to alias everything, let alone to have an industry standard alias list premade, because the system is already so simple that it wouldn't benefit us.
But the options exist, should you desire it that much, of course. But in 25 years on UNIX, never once have I heard even a story of a UNIX admin who thought there would be benefit to aliasing common commands to something super short. But on Windows, it's become way too common.
-
The alias was a moot point. The real commands are simple enough. There's nothing at all wrong with a New-localuser username command in any sense. Yes the Bash command of useradd is shorter, but there's no naming scheme for similar functions. Like what if you want to add an AD user? In Linux, completely different. In PowerShell, it's the same with only a minor but obvious difference. Instead of localuser, it's ADUser.
I'm sure you'll disagree in some tangential way, but IMHO it's great, simple, easy, efficient.
Then to pull and manipulate data is simple as well, by design. Each piece of data is something you can access directly using English... Name & value basically... without having to be an AWK wizard. Damn, that's a whole different discussion. I made the mistake of soda and chocolate before bed fml. I'm gonna try to force myself to sleep and see if I can find time tomorrow to catch up on story time.
-
@Obsolesce Plus, aren't we using tab to complete a lot of the time?
-
@wrx7m said in Managing Windows Local Users with Net User:
@Obsolesce Plus, aren't we using tab to complete a lot of the time?
That makes the abbreviations almost pointless.
-
@scottalanmiller True
-
@Obsolesce said in Managing Windows Local Users with Net User:
Like what if you want to add an AD user? In Linux, completely different. In PowerShell, it's the same with only a minor but obvious difference. Instead of localuser, it's ADUser.
This is where PowerShell shines a bit. Although it's a bit unfair in this particular case because we are talking about an ecosystem of PS being used for two PS specific tasks. Linux has no AD equivalent "one system to rule them all" and so doesn't have a benefit of being able to make one tool to do that for it.
Also, if you use PS on Linux, none of this works. PS uses the same useradd on Linux as Bash does. So it is really the Windows ecosystem being compared in that case, not an intrinsic functionality of PS. If you use PS on Linux, it doesn't manage additional features either.
-
I'd rather make a Powershell script than a batch file, but I'm still going to use executables to do tasks in my scripts when they are simplier, more specifically designed for the job, and there's not more advanced scripting required where I would benefit from using objects.
i.e. Copy-Item script vs using robocopy
Today I used icacls in a simple powershell script. And I always use the IIS management tool instead of the IIS powershell drive provider.
I think powershell's greatest strength is it's flexibility. Combine PS cmdlets, .Net, calling executables, even C# coded objects together to do what you need to do.
-
@scottalanmiller said in Managing Windows Local Users with Net User:
...Because of its simplicity, the net user command family is popular over remote shells such as those executed in a remote control application or through tools like psExec.
Net User Reference on Lifewire
Part of a series on Windows Systems Administration by Scott Alan Miller
Oh, man...... How true! I don't think I could get through my days anymore without net user and net accounts from a remote shell. They are the first things I do when someone says anything at all about "login issues".
-
@JasGot said in Managing Windows Local Users with Net User:
Oh, man...... How true! I don't think I could get through my days anymore without net user and net accounts from a remote shell. They are the first things I do when someone says anything at all about "login issues".
Yeah, I use these constantly. We use them through remote command execution so the PowerShell stuff doesn't work, so net commands are our friends.
-
@scottalanmiller said in Managing Windows Local Users with Net User:
@JasGot said in Managing Windows Local Users with Net User:
Oh, man...... How true! I don't think I could get through my days anymore without net user and net accounts from a remote shell. They are the first things I do when someone says anything at all about "login issues".
Yeah, I use these constantly. We use them through remote command execution so the PowerShell stuff doesn't work, so net commands are our friends.
You certainly can, if you setup the command line right and don't rely on independent connections.
We run multiline powershell commands through ScreenConnect sessions all the time to add and remove printers. You just have to paste it all into the windows at once, then hit send.
-
@JaredBusch said in Managing Windows Local Users with Net User:
You certainly can, if you setup the command line right and don't rely on independent connections.
We run multiline powershell commands through ScreenConnect sessions all the time to add and remove printers. You just have to paste it all into the windows at once, then hit send.
That's what we do too. If you can do it one line at a time, you can do it through ScreenConnect command. Just need to bump the #maxlength=100000 and
#timeout=90000 as appropriate! (values will differ)I have to say though, I'm using backstage more and more for the things I used to do in a command.
