Is there a way to search the event viewer in Windows Server 2003 and Windows Server 2008 r2 for a particular printer name using powershell or another cmd or program?
From time to time I have to search event viewer to see who printed a particular print job and we usually know what printer they printed to, but it is very tedious to search manually.
If anyone is able to give an answer you will need to give the whole code since I am new to writing code. Sorry, but thank you for your help.
Edit:
I know you can export the list but what I am looking for is a way to parse the description of the events.
Program installs to complete this will be installed on a seperate computer as we try to keep our servers as clean as possible. Unless it is a standalone file that can be removed as soon as it is run all code will be run from a remote computer.
I kow about Log Parser but am unsure how to make it run on another computer, I'm sure I'm looking right past how to do it.
I will be running all programs from a Win 7 Pro 64 bit pc.
You can use the Get-EventLog cmdlet to obtain event log entries. In this example I connect to a remote computer named STUDIO running Server 2003 and search for Print events initiated by STUDIO\Administrator.
Get-EventLog -ComputerName studio -LogName System -Source Print -UserName "STUDIO\Administrator"
The printer name is contained in the message property so you can do a regular expression match.
Get-EventLog -ComputerName studio -LogName System -Source Print -UserName "STUDIO\Administrator" | where-object {$_.Message -match "PrinterName"}
Related
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.
The situation. On a Windows 7 SP1 machine, I have updated with Windows6.1-KB2819745-x64-MultiPkg.msu. Furthermore, in PowerShell $PSVersionTable now reports ‘PSVersion 4.0’.
At present, my conclusion is that many PowerShell 4 cmdlets such Test-NetConnection, will only work on Windows 8.1. However, I was wondering if there was a work-around whereby I could import PowerShell 4 modules on my Windows 7 machine.
You cannot. They rely on the underlying features of the newer OS (8.0 or 8.1) and cannot be ported back to Windows 7 . The alternative is to write your own functions / modules to replicate the new cmdlets using .NET framework methods.
For instance, the Get-FileHash cmdlet is a one-liner in PowerShell 4.0, but to replicate in 2.0 we have to use .NET.
PowerShell v4
Get-FileHash -Algorithm SHA1 "C:\Windows\explorer.exe"
PowerShell v2
$SHA1 = new-object -TypeName System.Security.Cryptography.SHA1CryptoServiceProvider
$file = [System.IO.File]::Open("C:\Windows\explorer.exe",[System.IO.Filemode]::Open, [System.IO.FileAccess]::Read)
[System.BitConverter]::ToString($SHA1.ComputeHash($file)) -replace "-",""
$file.Close()
At least Test-NetConnection can be ported back to Windows 7. Just copy folders NetTCPIP, DnsClient, and NetSecurity from the supported Windows machine with the same PowerShell version (Windows 8.1, Windows 10, etc). Folder - C:\Windows\System32\WindowsPowerShell\v1.0\Modules. Then Import-Module -Name C:\Windows\System32\WindowsPowerShell\v1.0\Modules\NetTCPIP -Verbose
Alternatively, you can import a module from a remote machine (say win2012):
$rsession = New-PSSession -ComputerName win2012
Import-Module NetTCPIP -PSSession $rsession
I have had the same problem on my Windows 7 x64 and both solutions worked for me as of PowerShell 5.1.
Adding to Anton Krouglov's answer. PowerShell modules are cross-platform compatible. So a module copied from Windows Server 2012 R2 x64 can be imported to Windows 7 x86, and even if you are running as standard user without rights to copy them to C:\Windows\System32\WindowsPowerShell\v1.0\Modules you can copy it to any local folder, and run.
Assuming you copied the NetTCPIP, DnsClient, and NetSecurity modules from a Windows Server 2012 or higher machine, and save them to a folder you can import them using
Get-ChildItem -Directory .\psmodules | foreach { Import-Module -Name $_.FullName -Verbose}
Test-NetConnection -InformationLevel "Detailed"
As far as I know, Windows Server 2008 R2/Windows 7 simply doesn't have the counters that the .NET methods use to implement get-netstuff.
A new PowerShell version can implement hash compare, etc. since this is not related to anything, just a piece of code. But if you want to use, for example, Get-NetTCPConnection there is nothing to show.
I see several responses which assert portability, and my testing confirms their assertions:
Import all of the required modules, either from file, or via a PSSession to a host which has the required modules.
The architecture of PowerShell Console (x86 or x64) you run will determine which module architecture you import.
For those who are:
still unable to make this work
AND
do need a reliable TCP test, but may not need everything else provided by Test-NetConnection
AND
Need it all to work even on PowerShell v2.0
You may wish to try this.
# Create a TCP Client using .Net & attempt connection to target
$TCPClient = New-Object .net.sockets.tcpclient("[IP address or hostname]",[port])
# At the above point you may see familiar-looking Windows error messages in
# red text. (You may want to use "try/catch" if you intend to loop).
# Otherwise, check your new object's status to see if it worked
$TCPClient.Connected
# The response is either "True" or False"
# Now to avoid leaving idle connections, run:
$TCPClient.Close()
Naturally, it should be possible to create a loop which tests multiple connections, and outputs the results by selecting the properties of the $TCPClient.
My initial testing shows you would want to Select these properties
The address you tested
$TCPClient.Client.RemoteEndPoint.Address.IPAddressToString
The port you tested
$TCPClient.Client.RemoteEndPoint.Port
The result
$TCPClient.Connected
HIH
While PowerShell 4.0 is available on Windows 7, as Knuckle-Dragger states certain features rely on newer operating system functionality. Unfortunately Test-NetConnection is not available in Windows 7 as stated in the documentation.
Test-Connection, which is present, is basically ping. Test-NetConnection offers much more functionality, allowing a choice of things such as TCP ports, protocols, route tracing, and information levels.
There is a Send-Ping script available from the ScriptCenter in the TechNet gallery, but I think this is only really useful if you are stuck on PowerShell 3.0 for some reason.
I can only assume you installed the wrong package. Make sure you download the proper package from here.
Below you will see in running Windows 7 Service Pack 1 with PowerShell 4 using Test-Connection and Get-FileHash:
I've a powershell script which runs on server(test-server) and reads the log file of his client(DC1).
Both sides can ping to each other.
On both sides, firewalls are disabled.
Remote Desktop and Remote Assistance are enabled on DC1.
Get-EventLog System -ComputerName test-server -Source Microsoft-Windows-Winlogon # WORKS
Get-EventLog System -ComputerName DC1 -Source Microsoft-Windows-Winlogon # DOESN'T WORK
I run this script on test-server. As you see when I read the local log file on test-server it works fine but if I try to read the log file of DC1 remotely I get the error "Get-EventLog : The network path was not found.".
Screenshot of the error:
How can I avoid this error and read the log file of DC1 from test-server with using Get-EventLog?
#Lars Truijens's suggestion solved my issue. But other suggestions are also important to check.
So, here is the checklist if you get this kind of error when you try to get log files remotely:
Disable or set firewall settings on both sides.
Enable Remote Desktop and Remote Assistance on client machine.
Can you ping to the client machine?
Run dir \\dc1\c$ to see that you are allowed to reach to the
harddisk. (#Shay Levy's suggestion)
Run Get-Service -ComputerName YOURCOMPUTERNAME to see that you are
allowed to reach to the services. (#Shay Levy's suggestion)
Start the Remote Registry service. (#Lars Truijens's suggestion and
this made it work for me)
Here is the screenshot of this solution:
Starting the RemoteRegistry service did not help in my case.
Apparently, there is a difference between the remoting that is accessed via the ComputerName parameter in some cmdlets such as Get-Service and the newer form of remoting accessed with cmdlets such as Invoke-Command.
Since traditional remote access is implemented by individual cmdlets,
it is inconsistent (uses different techniques and demands different
requirements) and available only in selected cmdlets. The technology
used for remote access can vary from cmdlet to cmdlet and is not
readily known to you. Each cmdlet uses whatever remoting technology
its author chose. Most cmdlets use Remote Procedure Call (RPC), but
might also require additional services and settings on the target
system.
Beginning in Windows PowerShell 2.0, there is an alternate and more
universal way of accessing remote systems: Windows PowerShell
Remoting. With this type of remoting, Windows PowerShell handles
remote access for all commands. It transfers your commands to the
remote system using the relatively new and highly configurable WinRM
service, executes the code in a separate session that runs on the
remote system, and returns the results to the calling system.
http://powershell.com/cs/media/p/7257.aspx
When I swapped from this command
get-eventlog -LogName System -computername <ServerName>
to this
invoke-command {get-eventlog -LogName System} -ComputerName <ServerName>
I no longer got the following error
get-eventlog : The network path was not found.
This is incredibly difficult to do. I can't believe it. It should be so easy.
Anyway, using WMI (with both vbscript and perl) I'm able to start a process on a remote machine that runs a .exe, but I cannot get the output to write to a log. This is driving me nuts. I have to use WMI or powershell because I can't install anything additional on the remote machines, which are all Windows 2003 or newer. I also cannot assume that powershell remoting is enabled on all target machines, so I may not even be able to use powershell. This can cause a problem with powershell.
Here is what I'm trying to do in psuedo code:
servers = server1, server2, server3
for each server in servers
run command on remote server >> log.txt
next
I'm assuming you have powershell remoting enabled on all the servers and that you want the results saved in a local log file (ie not on each server)...
$Servers = "server1", "server2","server3"
Invoke-Command -ComputerName $Servers -ScriptBlock { ping.exe www.stackoverflow.com } >> c:\localfile.txt
This also assumes that your exe outputs to stdout, I think there will be issues capturing other streams.
A bit of background:
I'm trying to start and stop some performance counters remotely at the start of a test, then stop them at the end of the test. I'm doing this from an automated test framework from a Win2003 machine, the test framework executes commands without launching a console, some of the system under test is running Win2008. I've written scripts to choose the performance counters based on roles assigned to the servers.
My problem(s):
logman can't start or stop counters on machines that run a later version of the OS.
psexec can be used to run logman remotely, but psexec likes to hang intermittently when run from the test framework. It runs fine manually from the command line. I'm guessing that this is because the calling process doesn't provide a console, or some similar awkwardness. There's not much I can do about this (GRRRR)
I wrote a PowerShell script that executes logman remotely using the WMI's win32_process and called it from a batch script, this works fine. However, the test framework decides pass and fail scenarios based on the %ERRORLEVEL% and the content of stderr, but WMI's win32_process does not give me access to either. So if the counters fail to start, the test will plough on anyway and waste everyone's time.
I'm looking for a solution that will allow me to execute a program on a remote machine, check the return code of the program and/or pipe stderr back to the caller. For reasons of simplicity, it needs to be written in tools that are available on a vanilla Win2k3 box. I'd really prefer not to use a convoluted collection of scripts that dump things into log files then reading them back out again.
Has anyone had a similar problem, and solved it, or at least have a suggestion?
For reasons of simplicity, it needs to
be written in tools that are available
on a vanilla Win2k3 box. I'd really
prefer not to use a convoluted
collection of scripts that dump things
into log files then reading them back
out again.
PowerShell isn't a native tool in Windows 2003. Do you still want to tag this question PowerShell and look for an answer? Anyway, I will give you a PowerShell answer.
$proc = Invoke-WmiMethod -ComputerName Test -Class Win32_Process -Name Create -ArgumentList "Notepad.exe"
Register-WmiEvent -ComputerName test -Query "Select * from Win32_ProcessStopTrace Where ProcessID=$($proc.ProcessId)" -Action { Write-Host "Process ExitCode: $($event.SourceEventArgs.NewEvent.ExitStatus)" }
This requires PowerShell 2.0 on the system where you are running these scripts. Your Windows 2003 remote system does not really need PowerShell.
PS: If you need a crash course on WMI and PowerShell, do read my eGuide: WMI Query Language via PowerShell