🤘 11 reputation

GrantG

Standard

Joined: 10/29/2015

Last seen: 6/26/2019

Activity
  • When deploying, click the "Choose Targets", "PDQ Inventory", and you can specify collections.

    Or similarly on a scheduled deployment, go to the "Targets" tab, and click the "Choose Targets", "PDQ Inventory"

  • Likely related: https://community.pdq.com/posts/9713-wrong-uptime-value

    When fast startup is enabled, a "shutdown" is not the same as a restart, it's more of a hibernation.

    You can either disable it, or have users "Restart" instead.

  • If it helps, here's the conditions from my package that installs the Windows build 1809.

    It just checks to make sure that the version installed is an older version.
    If it's 1809 or newer, the step doesn't run because "conditions not met"

    I suspect Firefox has a registry entry that has the current version, that you could use in the same way.

    1809 Upgrade conditions

  • NirSoft makes most of their command lines pretty standard, so if you use one to log something, it doesn't take much to figure out the other programs.

    I use WinLogonView in a package with this "Install" step to save the results in a CSV file on a network share, one file per computer, named the same as the computer name.

    Install file: \\Servername\Sharename\Logins\WinLoginOnView.exe

    Parameters: /Source 1 /scomma \\Servername\Sharename\Logins%computername%Logins.csv

    Results in the bottom "Command Line" displaying this:

    WinLogOnView.exe /Source 1 /scomma \\Servername\Sharename\Logins%computername%Logins.csv

  • We have a command step that runs this as logged in user:

    C:\Users%username%\AppData\Roaming\Spotify\Spotify.exe /uninstall /silent

    But you can look and see in the application uninstall paths to see if yours differ.

  • Looks like is is just a PDQ thing. Maybe a bug, maybe intended function.

    Using a different type of command (like a command step) uses the variable correctly. So maybe a powershell popup with your custom message would work better in this case.

    And using a Message step, with a PDQ variable, will display that variable. But not easy/possible to set that with what you want.

  • What account is being used to deploy the package/step?

    It would need to be run as "Logged on User" for %Username% to match the person logged into the computer.

    Otherwise, it would show the Domain Admin, Local Admin, or System account you're deploying the step as.

  • PDQ and DCU work great together and do exactly what you want, single setup for every (compatible) model.

    I don't know how often they're releasing Windows 7 versions, though.

    https://community.pdq.com/posts/1173-deploying-bios-updates-with-pdq-deploy

  • https://www.windowscentral.com/how-disable-windows-10-fast-startup

    In Windows 10, if enabled, "Shutdown" is more of a "hibernate", and does not reset uptime.

    I too, was sure some users were lying to me, because even in Task Manager, the uptime would show multiple days when they claimed they had "rebooted every day". But the problems that would be fixed with a "real" reboot persisted.

    Note: "Restart" will do a regular reboot.

    With recent computers, and SSD's, startup is so fast you can likely disable this without any issues.

  • You'd actually want:

    Not Any >Files & Directories>Name Contains, Value=shutdown

    This one would test for if there were any files not named shutdown.

    Filter=Files & Directories, Name Does Not Contain, Value=shutdown

  • Quick and dirty option:

    If you make a package with a command step of "\\PathToFile\Filename.jpg" and run as "Logged on User", it would open the specified file in whatever program is associated with that file type. (Same as if they double-clicked it themselves)

    Should work with other file types too.

    But unless the contents of the file are self explanatory or they were expecting it, I'd guess about half my users would notice it, ignore it, wonder why that opened, and close it immediately.

  • Here's one way. Make each step the patch for a particular version, and add this condition for the step, customized to match that windows build.

    Screenshot

  • It's handy to make custom variables and use them in the filters, so you can define what is current, new, or old without needing to redefine your collections.

    Based on the variables in the "System" section, it appears that's how PDQ supplied collections do it too.

  • Anyone have a working Bluebeam Revu 2017 MSP update package?
  • A common issue.

    "Not any" "Member of Collection" Name Equals APP1 is what you want.

  • I think I ran into that a few years ago on something I was doing.

    Changing the systems date format changed the $(Date) variable that PDQ saw to the same format.

    Kind of a hack workaround, but it functioned. Hope that helps.

    Date format screenshot

  • Out of the box, it has some common pre-defined "collections" that will show which machines have those specific listed apps installed. (most of them for apps that PDQ Deploy maintains)

    It doesn't scan all the computers, find all the apps, and automatically make a tree of them.

    You should be able to go into a machines properties, and the Applications section, and see the complete list for that computer.

    You can also make your own collections. Like Autodesk. Or AutoCAD, or even each version of AutoCAD.

    I've made extensive custom collections for various apps, defined by things like version, location, computer model, etc. It's really easy once you get the hang of it, particularly since you can duplicate one and slightly change criteria on it to make similar ones.

    You can also use reports (including customized ones) to list all machines and all their apps and versions at once.

  • That would be awesome if it happens.
    We luckily only have 4 of those models, and 3 windows 10 builds to deal with.
    I'd guess a package per model would work best.

    But the random pattern that they release updates at makes these packages a pain to maintain for us.

    I know two other admins that make their own PDQ packages for them, I'm guessing there are many of us out there that would benefit from this.

    Now that the PDQ Windows Cumulative updates are separated into separate 32 and 64 bit versions (we don't have any 32bit), we save enough diskspace and network bandwidth to replicate some extra Surface updates across the DFS shares.

  • Could be related to this:

    https://www.pdq.com/blog/end-life-microsoft-xp-server-2003/

    "...version 14 requires Microsoft .NET Framework 4.5.2, which unfortunately does not work with Microsoft XP or Server 2003. This means that soon Inventory 14 will also no longer collect information about these old dinosaur target machines."