Can you check DATs into a "test" repository?

Given the 5498 DAT issue the other day I've been tasked with seeing if there's a way to do a "test" of the DATs via EPO before actually deploying to everyone.

So I guess is there a way to have EPO download the DAT's into a test repository or something and then have like 5-10 workstations assigned to that repo for updates and then when we're satisifed, move those into the "production" repos?

Re: Can you check DATs into a "test" repository?

Yes, you can tell the repository pull task to put them in the Evaluation branch instead of the Current branch. Then, for the system you want to test them on, create a new Agent policy for that machine and set it to use the Evaluation branch (this setting is on the Updates page of the Agent policy settings). While you are on that policy page anyway, you may want to also set the "Enable DAT file downgrades when the version in the repository is older than local version" option. Set this downgrade option for all the other systems' Agent policies also. Then, if you copy a DAT from the Previous to the Current branch (as many did yesterday), you can force your systems to rollback to the previous DAT by running the update task.

There doesn't appear to be a way to automatically move a DAT from Evaluation to Current, but you can do it manually from the Repository. You click the Change Branch link next to the DAT, then copy (or move) it to the Current branch. However, make sure you copy the Current branch DAT to the Previous branch before you copy the Evaluation branch DAT to the Current branch!

Re: Can you check DATs into a "test" repository?

Its always good to to have Daily Eval Dat set up and schedule it after McAfee released new DAT hours later. That way, you you will not have the bad DAT in your repo. DAILY EVAL save me yesterday's issue.

I set up 10 machines for Daily Eval DAT for testing purpose and if the DAT is good then the DAT will be published to all my systems (6000 machines) next day at 5am.

Re: Can you check DATs into a "test" repository?

How are you doing the flow and release of the DATs. Its it an automatic process.

If I check the packages into the Evaulation branch, I don't see an automated way to roll this into the Current branch. It appears I could check the packages into the Current branch and then do my testing from there and deploy users from the Previous branch.

Re: Can you check DATs into a "test" repository?

That's correct Rob. Mine is set up like this way and after testing is done both my evaluation and current have same DAT version but Previous branch has previous DAT. You can set up this "scheduled task" or Client Task

Re: Can you check DATs into a "test" repository?

I agree that automatically moving the DAT from the eval branch to the current branch should be an option (the same way it is to automatically move the DAT package from the current branch to the previous branch). Unfortunately that feature does not currently exist in EPO but it would be an excellent FMR.

Until such a feature is implemented you should be able to accomplish the same thing by using the "current" branch as your "evaluation" branch (they are just names afterall) and have the majority of your clients update from the previous branch.

Re: Can you check DATs into a "test" repository?

jstanley schrieb:

I agree that automatically moving the DAT from the eval branch to the current branch should be an option (the same way it is to automatically move the DAT package from the current branch to the previous branch). Unfortunately that feature does not currently exist in EPO but it would be an excellent FMR.

Until such a feature is implemented you should be able to accomplish the same thing by using the "current" branch as your "evaluation" branch (they are just names afterall) and have the majority of your clients update from the previous branch.

Good idea.

We pull DATs once a day to current for the test machines and the next day they are moved automatically to previous and most clients are updating from previous branch.

So DATs are one day delayed for our production clients but risk of false positives is minimized.