Dell updates Best practices
Ok my question really comes down to what is the best way to setup the dell updates. Maybe I'm just not thinking well today but it seems a bit cumbersome. do I have to create a smart label for each patch type or can I make a generic label that applies to most of my machines and then deal with one offs on a case by case basis. I just want to compare what is on my machines vs what is available in the catalogue, can someone please help me do this.
Well, you CAN do, what you described.
But the easiest way is:
1. create ONE Detect job for ALL devices. Since the Dell Patching checks if there is a Dell system, you don't need to do it via a smart label.
2. create ONE Deploy job for ALL devices. Same as before.
Since the Dell patches check if they are applicable for the system or not, you don't need to dig deeper here.
The only thing you need to keep in mind:
a) If you have _REALLY_ outdated BIOS versions the BIOS cannot be updated (the patching checks this with the applicability)
b) if you are using BIOS passwords you cannot patch BIOS directly.
So if you have a) or b) in your environment it becomes slightly more complex.
Action Plan would be as follows:
1. create a smart label for one system group and the minimal BIOS version they need to go to update (see the release notes of the BIOS updates by Dell)
As an example for a Dell Latitude E7450 with BIOS <A24 it would look like:
SELECT MACHINE.NAME AS SYSTEM_NAME, SYSTEM_DESCRIPTION, MACHINE.IP, MACHINE.MAC, MACHINE.ID as TOPIC_ID FROM MACHINE WHERE ((BIOS_VERSION < 'A24') AND (CS_MODEL like '%Latitude E7450%'))
2. create a managed install (download the exe file from Dell) Use E7450A24.exe /s /f /r to update, you can also add /p="BIOSPASSWORD" (using the real password) to that, so it updates and reboots.
3. enable the MI, so all E7450 are updated to A24. (in this example) They go out of the smart label so you can see how many are needing to be updated.
Repeat these 3 steps for all versions until the latest version and all systems you need to update.
Normally the updates should not ask anymore for a Bitlocker key since the updates disable bitlocker until the reboot is done.
If the update does not do this, you need to disable it manually (use a Script instead of the MI, which disables bitlocker before the update and sets a Runonce-Key to reenable after the reboot.)
ok well I'm not irritated with you but I got a very different answer from KACE. they said I had to make a label that contained all the pertinent driver packages, narrowed down by release date as well but that just sounded too tedious. I am trying to replace command update but at this point not sure if it is even worth it.
Ok well then my next point. I (thought) I had configured the dell detect/deploy setting correctly but it is failing to deploy open manage even though it shows it as missing. I have read through the admin docs and as it says that should be deployed on the first deployment of updates I'm just not sure why it isn't installing. Even though I have myself included in the test group that I am using I don't get any prompts when I manually trigger it but a colleague does.
Its not installed at all. I do see this in the admin docs though:
Any Dell devices that need to be updated must have the Dell Open Manage Inventory Agent installed, either the
client or the server version, as applicable. This component is included in all Dell Updates by default and there
is no need to add it manually. If the Dell Open Manage inventory client does not exist on a target device, it is
installed during the first deployment process.
So this says it should do it on its own but that did not happen.
When I set this up, I created a Smart Label looking for the Open Manage Inventory clients and ran some updates to get that deployed to endpoints. I then created two smart labels for devices. Both look for Dell as the manufacturer, and one for the presence of open manage inventory, and one for the absence of it. The label for the absence of the Open Manage Inventory Agent provided the device label I could use to continuously target the deployment of the client. The other was used for targeting the rest of the Dell update content. I hope this helps.
Another point to note here is that the Kace dell patcher, and probably the other vendor patching options don't suspend bitlocker when doing firmware updates, resulting in you needing to re-enter you unlock code. If your configured to need this every boot, no issue, however i suspect most are not.
Personally use the Kace for reporting, as well as patching drivers, but script Dell Command Update to do firmware updates, which can suspend Bitlocker, as well as reboot the machine. Use dell command update on the K2 as part of a scripted install to install drivers and firmware updates then as well. Find the feed that goes to the K2 only good enough to get the machine imaged, and rarely as current as what the K2 gets.
Thanks for the input everyone. I have ultimately ended up setting up all the labels to segment out all the dell updates into category after running the initial detect looking only for open manage. so now I have our roughly 5 hundred pc's grouped up and patching in cycles. After the initial open manage detect and deploy things are starting to level out