I'm trying to write a script in powershell that will get all the installed printers in each computer.
At my organization we use a print server running win server 2019 to manage and share all the printers.
For some reason the commands
Get-Printer and win32_Printer return only the locally installed printers (which are the windows defaults like ms print to pdf).
I've tried to run the lines on the server itself and got the full list cause they are installed locally.
Is there a way the get a printer that was installed from a server? And in the future I will also want to install and uninstall those printers via powershell.
I have a function that does this, specifically, for our environment, but it relies on several other "self-coded" functions, so I'm not going to paste it here.
What you need to do is connect to the registry on the remote computer and interrogate it. The subkeys for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Connections are GUIDs, and interrogating the PRINTER property of each of those subkeys will give you the UNC pathname of the connected printer.
This does NOT return the locally-defined printers; for that, you need Get-Printer.
Related
I've created a script which calls 'dfsutil', and is available for all the members in my team. Some members don't have RSAT (dfsutil) installed locally, so I'd like to 'trigger' a .ps1 script independently of the source PC (PC1) to be run on a server (Server1) which has 'dfsutil' installed.
It's easy enough to trigger a remote PowerShell script from the source 'PC1' by dot-sourcing it from 'myscript.ps1':
. \\Server1\scripts\dfsscript.ps1
As we already know, the above will fail as PowerShell is looking for 'dfsutil' locally on PC1, rather than on the server 'Server1'.
'dfsscript.ps1' has been written so it can be run independently, without need to return the values to PC1.
I can't seem to find any documentation which shows how to initialise a remote script which only uses the values and conditions of the OS it was triggered on.
Any thoughts?
Dot-sourcing is about the scope of a PowerShell session, but doesn't include the computing environment, so what you are doing won't get the script on Server1 to run from Server2, but still act like it is on Server1 with access to all of Server1's installed apps, etc.
What you need to do is use PowerShell remoting to actually run the script on the remote server (i.e. trigger from Server2, but execute on Server1). For example:
Invoke-Command -ComputerName Server1 -FilePath <path>\script.ps1
I'm still learning about PowerShell and SCCM.
At the moment i'm trying to get all resource names of a device collection into an array variable. I don't know if this is possible?
Example:
Computers: Win7, Win8, CM02,....
into a variable like:
$computers = COMPUTERNAMEWIN7.local.domain.lo, COMPUTERNAMEWIN8.local.domain.lo, COMPUTERNAMECM02.local.domain.lo
This is what i'm trying to achieve:
I'm trying to deploy LibreOffice to all computers i have under my control in SCCM 2012.
So i have a Device Collection: "All Systems" with all these computers in it.
and then use aForeach-Object command to copy and install the .Msi file of LibreOffice.
Is there a PowerShell command to get these into an array like the example, when specifying the device collection name ?
thank you :)
I'm working with DNS resource records in Powershell 5 using code that I inherited from the guy who was trying to do this before me. The cmdlet I am trying to use is Add-DnsServerResourceRecordA.
Part of his code has import-module certain folder\PowerShell\Modules\DnsServer. The weird thing is, it seems like as I was trying bits and pieces of the code earlier, I was able to use the add-DNSblah cmdlet. Now, after It ried running the whole script including the import-module, Powershell is saying that the cmdlet does not exist natively, and when I import the module and run it it is giving me Add-DnsServerResourceRecordA: Invalid Class.
It is my understanding that Add-DnsServerResourceRecordA should be included in my normal Powershell 5.0. Could that Import-Module have permanently damaged PS somehow? Why else would the cmdlet not show up, even in a Get-Command "dns"?
I'm pretty sure you will need the Remote Server Administration Tools (RSAT) installed to have these cmdlets available on a non-server Windows OS.
You can download them from this page: https://www.microsoft.com/en-gb/download/details.aspx?id=45520.
Not really sure why the Import-Module does not fail if the DNSServer module is not present on the system.
If RSAT are already installed, you can try to reinstall them.
I have modified a script to standardise our organisations signatures in Outlook. The script uses a Word document as a template for the signature and extracts user details from the Active Directory info on our SBS 2003 server.
I am logged in as a Domain Admin and the script works ok for my Outlook signature (there are a couple of errors but it creates the 3x outlook signature files that I need). I can't get it to run on any other computer (but this is the only one with Powershell installed) nor will it run for any other user on this computer.
I would really like to be able to run the script from each workstation. This would be easy if it was a batch file, but it won't work as a powershell script. Do I need to install Powershell on every workstation or is there a simpler way to get it to work?
Also,
I wonder if there is a problem with the script that is not allowing other users to run it from this computer (even with Powershell installed).
Cheers,
Greg
Yes, you need Powershell installed on every machine where you want the script to run. It's included with OS on everything from Server 2008 and Windows 7, but otherwise you'll need to install Powershell manually.
You will also have to enable remote scripting on each machine, since this is disabled by default (for security reasons). Take a look at the following help pages for information and instructions on how to set up:
Get-Help about_remote
Get-Help about_remote_FAQ
Get-Help about_remote_requirements
Get-Help about_remote_troubleshooting
If you want to use PowerShell remotely you will need to install it. If you don't want to do that you could look at psexec - that's one of Sys Internals great tools. It will enable you to run commands\scripts remotely.
I have a different suggestion. Could you generate these signature files for your employees on your machine and then push the signatures out to all the other machines?
I need to know if it is possible to run powershell remotely in the following scenario:
I have a Windows XP box WITHOUT Powershell installed. From this box, I would like to run a PS script located somewhere like: \\mypc\C$\Scripts\information.ps1.
The script should be run against the machine where it resides. In this case, the “mypc” machine would be running the script and returning the result to the XP machine.
What makes this difficult is the fact that I cannot install Powershell or any third party apps on the Windows XP machine.
It’s a long shot but would this be doable?
Thanks!
While you can't actually run the script on the local machine without PS installed there, depending on what you want to actually accomplish you may be able to run it locally and simply access the remote resources. Most of a machine's resources are typically available remotely (File System, Registry, WMI, etc.) depending on the security on the machine.
EDIT: Now that my complete misunderstanding of the issue is cleared up, my answer would be: No, you do not need to have Powershell installed on a local machine to run a script on a remote machine that does have Powershell installed. Just use PSExec to kick off the Powershell process on the remote machine. I realize that the OP cannot install 3rd party apps, but there is absolutely no install associated with PSExec, it is a completely stand alone exe.
It has been a while since I had to do this so I did a quick check. This at the command line worked for me:
psexec \\REMOTEMACHINE "C:\Windows\system32\WindowsPowershell\v1.0\powershell.exe" -File C:\temp\test.ps1 -NoProfile -NonInteractive
You need to have Powershell installed. This isn't possible :(. Sorry.
Using Psexec is the only way I can think of too. However, if you are using PSexec.exe using alternate credentials, the credentials are passed over the network in plaintext. Something to be wary about if your network is visible to other people.