I ran into a language issue the other day when writing a PowerShell script that uses net localgroup and thought it could be useful to others:

Depending on the language your Windows device is set to, the local Administrators group will be different, so the typical net localgroup administrators domain\user /add command will fail.

Implementing the following will grab the actual name of the group by it's SID first, then use that result.
Note that this is written to work in PowerShell, not CMD.exe.

# Gets the name of the local Administrators group in appropriate language $localAdminGroupName = (Get-WmiObject win32_group -filter "LocalAccount = $TRUE And SID = 'S-1-5-32-544'" | Select-Object -Expand name) Write-Output "Local Administrators group detected as: [$localAdminGroupName]" # Sets the users as a local admin using appropriate local Administrators group name net localgroup $localAdminGroupName domain\user /add # Gets local Administrators group members net localgroup $localAdminGroupName

Good find.

@scottalanmiller said in Managing Windows Local Users with Net User:

@JasGot said in Managing Windows Local Users with Net User:

I'm using backstage more

I assume that this is a component of another product?

Part of ConnectWiseControl. (or ScreenConnect as we still call it around here.)

It's at the bottom of the View tab when attached to a guest. Takes you to a new sessions as a System account with a command prompt and powershell window already open. No limit to what you can accomplish there. many gui apps will run in backstage too.

Topic has been forked, please keep discussions of OS comparisons to a different thread.

https://www.bleepingcomputer.com/news/microsoft/microsofts-april-2019-updates-are-causing-windows-to-freeze/

Looks like it isn't just Sophos.

@pmoncho said in The Hidden Cost of Licensing Windows Server - Activation:

@scottalanmiller said in The Hidden Cost of Licensing Windows Server - Activation:

Just looking at this with a customer that just put in a new Windows 2019 server. The machine was purchased with a volume license agreement for Server 2019 Standard. Everything should be super easy, in theory. Problem is, license key from the volume license center doesn't work. We spend a bit of time trying to get this to apply, but no luck.

I have run into a similar situation this morning and not being able activate the VLSC liscense.

Before I decided to call MS and getting frustrated, I was able to activate from an elevated command line.
cscript c:\windows\system32\slmgr.vbs /ipk <product key>

Throwing this out here in case someone comes along this post at a later time.

I've heard that that often works. We had tried that in our case and it had failed.

@scottalanmiller I realise this is an old topic, but I've been fighting something similar all day. As it turns out, the implementation of PTY (and also TTY) has changed in recent versions of OpenSSH for windows. When the SSH session is built from within a script, the new OpenSSH implementation detects that the session is not setup from an interactive terminal, and therefore does not assign a PTY to the session, which results in the unability of the Get-Command command to send its output to STDOUT, hence the access denied error. Solution is (at least in the situation I am in) to use the -t (or even -tt) flag with the ssh command to set up the session

@Reid-Cooper said in General Guidance on Windows Admin Center WAC:

@Obsolesce said in General Guidance on Windows Admin Center WAC:

Yes you do need to either add other devices manually or by importing a list... but it's a one-time thing so it's a non-issue IMHO.

Not bad for tiny environments. But at any scale, how does that handle machines being added in the future? You have to manually add every new machine after every change to WAC?

I've only had about 100 servers and a handful of Win10 in it, so I'm not familiar with handling that at scale. It really only requires a txt file of a list of devices which is simple to maintain in any aspect. I only had to import that to get everything back in. If I added a new server, I would add it to the text file then add that server.

@scottalanmiller said in Estación de trabajo con 10 segundos de atraso en el reloj:

@dbeato said in Estación de trabajo con 10 segundos de atraso en el reloj:

@scottalanmiller said in Estación de trabajo con 10 segundos de atraso en el reloj:

Anyone know what the normal variance on Windows boxes is when not using a local time source? How close in seconds would we even expect a site to be able to be?

You can have it up to 5 minutes from the Domain Controller Servers time.

No DCs. No AD.

Gotcha, I am still trying to see what is the issue. 10 seconds is almost unnoticeable. What is the purpose?

Our go-to solution for VSS problems is to set up a dedicated snapshot volume. Otherwise we were getting timeouts and M$ does ugly things that don't make sense when VSS doesn't work properly.

I had a similar issue in a workgroup with drives disconnecting. A bunch of Googling brought me to this.

https://support.microsoft.com/en-us/help/297684/mapped-drive-connection-to-network-share-may-be-lost

That seemed to fix the issue for me.

@Dashrender said in Microsoft Security Essentials - Script?:

Do you have a remote access solution for these machines?

If not, Mesh Central might be a real life saver - then you could remote in and run these commands. No driving required.

What do you meant "Remote access solution"?
if the question is "DO i have remote access" ?
then the answer is yes .

@Emad-R said in Download Windows Server 2019:

@scottalanmiller

https://software-download.microsoft.com/download/sg/17763.253.190108-0006.rs5_release_svc_refresh_SERVER_EVAL_x64FRE_en-us.iso

Thanks @Emad-R with this link you don't have to go through all the paperwork.

Worth the try checking it @dbeato thanks, will try it once I can remote back into the machine today

@gjacobse said in Add a User to Remote Desktop Users in Windows Remotely:

I seem to remember doing this via ScreenConnect CMD

Only works if SC is installed, which if it was, we'd not need to do it 🙂

@Kelly said in Use Powershell to audit Windows service accounts:

Unless you're wanting to use Powershell for a learning experience you might look at something like this: http://www.cjwdev.com/Software/ServiceCredMan/Info.html. If you still want to use the Powershell route this might be a good way to check the success of your script.

That looks like it will do exactly what we want... thanks for the link.

Not yet.