I’m sure you’ve run into this before; you’ve spent precious time creating a silent deployment, determining targets that need an update, and then your deployment is slowed down due to numerous offline targets. What to do? Well, the answer is simple, PDQ Deploy is coming to your rescue.
We recently started this new series to bring you delightful little nuggets of information for PDQ Deploy. Last time we brought you details on the Copy Mode, today we bring you the Run As options.
There are situations when you need to change up how PDQ Deploy will run deployments. For the most part, running a deployment as the Deploy User is appropriate and, indeed, recommended. There are instances when you need to run certain package steps (or even entire packages) as a Logged on User or as the Local System account.
Why waste time with small talk, let’s get right into the meat and potatoes.
So, you’ve been using PDQ Deploy for a while now and you’ve got the basics down, but you might not have explored all the smaller items that make it all the more powerful.
In this new series, we will bring to you some nuggets of useful tips, tricks, and helpful information that will help you become more effective in your SysAdmin chores. (Turn those skills up to 11!)
As the saying goes, “The more you know”… well, then the more you’ll know.
Pink and Blue are at it again in Episode 2 of Sysadmin vs. Sysadmin. In this episode, the boss is on the prowl. Watch as Pink and Blue seek to incite disciplinary action on one another. Who will win?
Watch to find out and stay tuned for our next episode.
If you missed the premiere episode, Deploy the Dog, check it out here.
Welcome back to the show! Last time, we showed you how to export your Custom Fields to a .csv file using Reports. If you are a true PowerShell fan, you might have been waiting with bated breath for this blog to see the magic happen in PowerShell.
This will be very important for all of you using the Central Server who realized that all your precious data in Custom Fields did not transfer to the shared database automatically.
So, how are you going to get all that fancy data into the database housed on the new server?! Well, so shall it be requested, so shall it be blogged. Exporting Custom Fields data with PowerShell can be broken down into the following three easy parts:
Microsoft has baked into the upcoming Fall Creators Update of Windows 10 an interesting little feature called Controlled Folder Access, which allows you to set restrictions on which executables can make changes in certain directories. In the recent Insider Preview builds of Server 2016, Controlled Folder Access has been present, so it’s probably safe to assume the next iteration of Windows will also include this. This addition appears to be in response to recent highly-publicized ransomware attacks.
Plenty of security companies offer products that provide control over which applications are allowed to execute in which directories. Carbon Black, Trend Micro, McAfee, and many others have application control solutions that allow you to create and manage policies to keep your network safe while allowing your end-users to do their work. Make no mistake, this feature in Windows is not quite as sophisticated, but it can provide a fairly useful service for individual users if configured wisely.
So, you ready to rumble and enable it? …hold that thought!
If not implemented properly, this feature has the potential to prevent remote management such as software deployment and inventory collection, aka PDQ Deploy and PDQ Inventory.
Dear Admins of Microsoft XP and Server 2003 clients,
We feel your pain and offer our deepest sympathies. However… computers with Microsoft XP or Server 2003 can no longer be managed using PDQ Deploy 14.
XP and Server 2003 were end-of-lifed by Microsoft in 2014 and 2015 and have been unsupported by PDQ.com since 2015. Unsupported by PDQ.com means that testing PDQ Deploy and PDQ Inventory with XP and Server 2003 was officially stopped. While our products still worked with these two operating systems, without testing them, we could no longer guarantee functionality.
Are you a fan of Spy vs. Spy, but it’s just not nerdy enough for you? We bring you Sysadmin vs. Sysadmin. In this premiere episode Pink and Blue go head to head. Who will win?
Watch to find out and be sure to check out Episode 2: Solitary Incitement.
But, what about all that awesome custom data in your local database? You know, that data that you painstakingly input by hand for each and every computer in your database?
How are you going to get all that fancy data into the database housed on the server?!
“Good news, everybody!” It’s fairly straightforward to grab and export this info using a PDQ Inventory report. I’ve broken it down for you into 3 easy parts. (If you would rather use PowerShell, see Part 2 of this blog.)
Good news, everybody! Subexpressions are the answer! (Not to your sandwich woes, though. You’ll still need to work on that one).
Did you know that you can do subexpressions within your strings? *le gasp!* Did you also know that you can use subexpressions to access object properties within strings? *le double gasp!*
You can use the subexpression operator
$() to do some awesome things within strings. For more information on PowerShell operators, check out this link.