Tip:
Highlight text to annotate it
X
Hey everybody, I'm shame from Admin Arsenal. let's go ahead and talk
a little bit about best practices for keeping your PDQ deploy
installation running smoothly and quickly. There's a few things you can do to
make your deployments go a little faster
and maybe make the console experience a little smoother for you.
Go to your Preferences, that's where we'll do most of our work here.
in the Deployments panel, first off your Offline Policy
if you don't want to
try deploying to machines that are offline, change your offline policy to Do Not Attempt.
This means that during your deployments,
PDQ Deploy will actually ping all the targets
prior to pushing the package out, and if
a machine doesn't respond to a ping, it's not even going to attempt to push that package
out. If you don't do this, if you keep it to the default,
Attempt Deployment, it could take an extra 60 seconds if a
machines offline before it times out
trying to connect. If you want to do wake on LAN
if you haven't had PDQ Inventory installed you can do Wake on LAN, just so
you know
that could take a up to six extra minutes per target,
if that target happens to be offline. follow waits for that target to come back
on.
I personally I like to use do not attempt.
but, obviously if it fits, you do it for your environment. Cleanup,
we have a default cleanup of 30 days what this means is we keep your deployment
history for 30 days.
If you want to increase that some people like to even keep it for a year,
by all means do that just keep in mind that can,
that will increase the size of your database depending on the number of deployments
You have, and for you know,
for you folks that have thousands of computers and a lot and appointments if
you keep this 365 days or 180 days
your PDQ Deploy database is going to get very large that also means that
that when you start to PDQ Deploy it's going to take a lot of memory just a load that database up.
So, just keep that in mind, try to find the sweet spot there
for your cleanup and if you want to keep that, if you never want to delete
any of your deployment history, keep in mind that's only
the history, then you can set that to 0 days and it will never
delete the history. But obviously your database can get very large.
We're going to come down to
Performance. Notice we've got two
values at the top, the Concurrent Targets per Deployment and
the Total Concurrent Targets. The target is
8 per deployment and 32 total.
overall appointments concurrently. You can use this, tailor it to fit your
environment.
If you want to increase say, current targets for deployment, maybe if you want
to go to
16 and maybe increase this up to 64,
obviously you can do that just keep in mind that
the more concurrent connections you have
you can overload your neck on your
deploy console. And it takes more memory
more processing power, and you need to have a faster disk because
this many connections you're gonna be having a lot of data written back to the
database
on your console for statuses of deployments.
So find the sweet spot there as well. We don't recommend keeping... some
of our customers like to put this to a hundred or 200 concurrent targets,
and that really can bog your system down.
The bandwidth limit: 50 percent is the default.
this only applies when you have your copy mode set to push, just so you know. If you
want to,
if you use a pull Copy Mode then this
values doesn't apply. Also notice
in this case I've got my TCP connection set to disabled,
that's a personal preference. Generally speaking
this is fine. You'll notice a lot faster connection to your computers
but if you keep it the default or timeout, that's just fine as well. Just so
you know.
You can increase... you can add about 20 seconds to a
connection. I like to keep it disabled.
let's see I think thats for the most part
that will nail it down. Let's go real quick to your
database. So if I keep my deployments,
my cleanup history at 30 days on the database
you might wanna optimize your database every 30 days because
what this does is actually free up space
from data that was deleted. If you clean up your deployment history every 30 days.
Schedule and optimize: optimize your database.
That will keep your database relatively small,
manageable. But when you do that it does stop the background service while it
optimizes. So that means any schedules
that are supposed to kick off won't during that time,
and the deployments that are going on at that time will also be aborted.
just keep that in mind. Alright, I'm Shane. Hopefully this answers some of your questions.