This question already has an answer here:
Real number of TotalPages of a PrintJob (Win32_PrintJob)
(1 answer)
Closed last month.
I tried to follow the example of WMI scripting (VBScript) to obtain several info from the current Windows OS, including the print job. Both are working successfully.
' My SampleCapturingPrinter.vbs
' ———————————————–‘
Option Explicit
Dim objWMIService, objItem, colItems, strComputer
' On Error Resume Next
strComputer = "."
While True
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Printer")
For Each objItem in colItems
Wscript.Echo "- " & objItem.DefaultCopies
Next
Wscript.Echo "====================="
WScript.Sleep 1000
Wend
WSCript.Quit
' End of My SampleCapturingPrinter.vbs
' ———————————————–
But from the official documentation , there is no info about -current number of copies- ? So my question is... where is the counter located / stored exactly?
If let say the user click Print through out any app and set the copies to let say '3 copies' and pressed (Print). The printer job tracked nicely, but I don't know where the 'number of copies' stored.
CMIIW, is it possible through out WMI to obtain the current details?
As I've said in other answers, WMI has problems with printing, and it doesn't provide copies.
The question itself is problematic, similar to N-Up. Early printers didn't have any concept of copies, so the Windows printing APIs support the concept weakly with an optional copies entry in the DEVMODE. To complicate things, some apps (notably some versions of MS Office) handle copies internally, while some drivers don't use the DEVMODE entries.
Related
I am getting the current screen resolution with:
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_VideoController",,48)
For Each objItem in colItems
Wscript.Echo "Horizontal resolution: " & objItem.CurrentHorizontalResolution
Wscript.Echo "Vertical resolution: " & objItem.CurrentVerticalResolution
However it returns the resolution of the real monitor and doesn't work in an RDP session. How can I either get the RDP resolution or just get the session type to prove I am in an RDP session (and can therefore implement a work around)? This is a major issue when RDPing from a MacBook with a high resolution.
Thanks
I am using a simple vb script to get CPU0's load percentage, but the WMI enumeration is significantly slower on Windows Server 2016 then older versions and I need to optimize the speed.
Here's my short script:
Option Explicit
Dim objWMIService, processItems, objitem, loadpercentage
loadpercentage= 0
Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
Set processItems = objWMIService.ExecQuery("SELECT * FROM Win32_Processor _
WHERE DeviceID='CPU0'", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
For Each objItem In processItems
loadpercentage = objItem.LoadPercentage
Next
There's a 10 second delay between setting processItems and entering the For Each loop. This same script on older versions of Windows Servers takes 2 seconds. Can anything be done to optimize the WMI enumeration? Thanks in advance.
Try to not use * in your WQL queries. No filtering by any property just slows WMI queries very much. Instead of that, specify exacly the properties you need and nothing else:
SELECT LoadPercentage FROM Win32_Processor WHERE DeviceID='CPU0'
I have the code below which will get drive p(a network drive) and throw up a message box with its total & free space. Total is reporting fine but for some reason free is throwing up a completely incorrect value.
Set filesystemObject = CreateObject("Scripting.FileSystemObject")
Set drive = filesystemObject.GetDrive("P:")
total = round(drive.TotalSize/1024/1024/1024)
free = round(drive.FreeSpace/1024/1024/1024)
MsgBox(total & " " & free) // throws up 400gb total and 34gb free
Free should be 1.7gb, which I have verified as being accurate on the actual server. I also checked the total free space across all drives and this total came to 25gb(across 4 drives) so I cannot see that being an impacting factor.
Does anyone know what could potentially be throwing this value off?
Edit:
Bonds answer below is marked correct as its a secondary method of proving the code above is accurate. If you come across this problem there are several features which may impact the values that you are returned.
1) Quotas being enabled.
2) Your admins rigging free space to not be accurate. In my case the admins had been rigging the share to display a much lower free space than there actually was in an effort to make users think about what they are storing.
I've had trouble trusting the FSO's numbers in the past, too. Have you tried using WMI?
Const strDrive = "P:"
intFactor = 1024 ^ 3
Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colItems = objWMIService.ExecQuery("select * from Win32_LogicalDisk where DeviceID='" & strDrive & "'")
For Each objItem in colItems
MsgBox "Size: " & FormatNumber(objItem.Size / intFactor)
MsgBox "Free: " & FormatNumber(objItem.FreeSpace / intFactor)
MsgBox "Used: " & FormatNumber((objItem.Size - objItem.FreeSpace) / intFactor)
Next
I wrote a program that reads system information from registry/CPU, like CPU speed, amount of RAM, GPU card name etc.
On Mac OSX I can retrieve information about hardware model (for example MacBookPro8,2 is MacBook Pro Core i7 from early 2011). While I know that it's impossible on desktop Windows PC because they are not standarized, a lot of people are using Windows notebooks. And I don't think that custom-build notebooks are very popular.
So my question is, is it possible to obtain model information like "Samsung Series 9 900X3A-A03"? Or at least vendor information (Samsung)?
Use this in a .vbs file to get make / model #. You can also use the objects by having the .manufacturer and .model method write to variables.
defining and assigning "." to this value makes the script run on the machine you are executing it on. If you have admin privileges, you could run this on another ocmputer on the network by specifying the computer's network name in:
strComputer = "SomeComputer"
Paste into a VBS:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem")
For Each objItem In colItems
WScript.Echo objItem.Manufacturer & " " & objItem.Model
'WScript.Echo "Model: " & objItem.Model
Next
I understand that the FAT file system stores its time stamps for files (modify date, etc.) with a 2 second granularity, and NTFS stores them with a 100 nsec granularity.
I'm using VBScript with FileSystemObject to show file details. The function file.DateLastModified shows me the date with a 1 second precision (on NTFS).
Is there a way to show the time stamps with a precision according to the internal storage granularity of NTFS. I'm imagining something like 8/9/2010 14:40:30,1234567
And if not with VBScript / FileSystemObject, would there be any other way?
File timestamps are held as FILETIME in NTFS but the millisecond portion is not passed to the Variant DateTime so VBS doesn't see it. The WMI object can support this though.
Sub PrintTimestamp(sFilename)
Set oWMI = GetObject("winmgmts:!\\.\root\cimv2")
Set oFiles = oWMI.ExecQuery("Select * from CIM_DataFile where Name = '" & sFilename & "'")
Set oDateTime = CreateObject("WbemScripting.SWbemDateTime")
For Each oFile in oFiles
oDateTime.Value = oFile.LastAccessed
WScript.Echo oFile.Name & " " & oDateTime.GetVarDate & " " & oDateTime.Microseconds
Next
End Sub
PrintTimestamp("c:\\temp\\demo.vbs")
Full-precision file times are easily accessible via the native Windows API. This MSDN article explains how to do it: File Times.
I do not know of any way to read the 64-bit FILETIME from VBS, especially since VBS does not handle 64-bit numbers natively. Once you have a FILETIME you can parse it with SWbemDateTime, though. Here is an example.