Automatically Provision Dell Servers
This tutorial covers the various ways to automatically provision Dell servers.
Helpful Links
- OME Template Function
- OME Server Initiated Discovery
- Enabling OME Server Initiated Discovery
- OME Download
- OME Licensing Info
- OME Auto Deploy Instructions
- OME Create Auto Deployment Targets
- Dell Whitepaper on OME Autodeploy
- Dell Update Manager Plugin
- Dell Server Initiated Discovery Whitepaper
- Discovery with Ansible
- OME API Discovery with Python/PowerShell
- Dell's API documentation
- RedFish Documentation
Overview
There are two predominant workflows for automatically deploying and provisioning Dell servers.
- Use OpenManage Enterprise (OME). OME is free.
- The auto deployment feature requires the OME Advanced license to be present on the iDRAC but this is usually added by default by Dell. In my personal experience, I've never seen a server sold without it in all my time at Dell. More info about the difference between the licenses is here. If this is a concern just ask whoever is selling you the server (whether it be Dell directly or a partner) to make sure they put the OME Advanced license on the server if they haven't already.
- I have seen two variations of how OME deploys the server depending on how you want the initial discovery to occur.
- Manually via the Dell APIs.
When to Use OpenManage Enterprise (OME) and When Not
Warning: Honesty based on personal experience ahead. Forthright commentary serves to save others from mistakes I have personally made or watched others make.
Unless there is a compelling reason not to use OME, it makes life significantly easier and is probably the better solution.
Potential good reasons to not do automated deployment with OME (I bolded the automated deployment bit because for reasons I explain below, you're still going to end up using OME):
- You are using Bare Metal Orchestrator (BMO) and have a workflow built there. If this is the case you are probably a TELCO or something of equivalent size and aren't reading this article
- You have a significant investment in a multi-vendor deployment solution and already have the in-house personnel and talent up, running, and using this solution
The worst reason to not do this with OME:
- You are me at 27 years old and think building everything open source is better because you haven't yet had to handle or pay for manpower in the maintenance phase of code you have written. (Ok, so I actually never made this mistake with OME, but I did with other things.)
Benefits of doing this with OME:
- Dell is on the hook for support
- Unless you're going to build an entire patch management framework from scratch, which is a very bad idea because new you are on the hook for making sure patches are applied in the correct order, handling failures, reporting, code maintenance, repository maintenance, and all the other not-so-fun things that come with a custom patch management framework, you are going to want to use OME for patch management anyway.
- I've worked with the TELCOs, they use OME. I cannot think of a valid reason to ever re-invent this wheel.
- I am also assuming you are not so cruel to your administrators that in 2024 (or whenever you read this) you will make them do manual patching.
- This supports custom repos with Update Manager Plugin
- OME will automatically take care of BIOS-config templating.
- Again, this is another function you will have to manually build and maintain if you don't use OME. I have personally done this one. It's doable, but requires a lot of tedious, boilerplate, code and you will have to write a bunch of logic to handle all the boarder cases you might encounter. This becomes particularly miserable if you have multiple different servers you have to independently account for with multiple different BIOS templates.
- Again, this is why TELCOs use OME
- You don't have to maintain a custom patch repository if you are on the internet.
- If you are a government or other customer in a SCIF or other such facility see Offline Updates with OpenManage Enterprise
- OME provides power monitoring
- OME provides config diff tracking
- OME gives you a one stop shop to monitoring to including grouping servers and applying policies to them based on those groups
- OME provides a convenient panel for getting to all the iDRACs
- OME will track all your warranties
Those are just the common benefits, there are a bunch of niche things it does as well that don't apply to everyone (ex: ServiceNow integration).
OME Workflow
There are two workflows I see with OME: one using server initiated discovery and one where you do discovery with some code framework and load that into OME. If you are in a Dell environment then you probably just want to go ahead and use server initiated discovery. It's one less thing you have to maintain and it again is supported by Dell end to end. If you have a multi-vendor environment and have to build a discovery framework regardless, it may make more sense to centralize discovery in your custom framework. I describe both below.
An important note on understanding how OME works: OME controls the servers over iDRAC's RedFish API. Most everything you could do directly to the iDRAC over RedFish, you can also do centrally with OME.
Overview of Configuration for Both
See this link for a Dell whitepaper on auto deploy.
- Configure OpenManage Enterprise (OME) with the BIOS templates you want. You’ll configure the BIOS templates by taking a representative server and extracting the BIOS from it. OME has a function for doing this so you just make one server look exactly the way you want the rest, point OME at it, it saves that config, then you make that your template.
- Configure OME for auto deploy to include pointing it at whatever ISO you want to be deployed to the different target servers. See this documentation
- Create a list of service tags with your various servers and put them in a CSV file
- Create the auto deployment targets in OME. See this documentation
- Create the auto deployment targets in OME. This will tie specific templates/ISOs to specific groups. Those groups will be assigned to servers based on their service tags and then automatically applied.
- ISO files are mounted via network path via either CIFs or NFS
- Use either a custom discovery framework via APIs or configure Dell's Server Initiated Discovery to register the servers with OME
- Turn on new servers and watch them build themselves from nothing
- As an added bonus, configure firmware updates in OME and set it to automatically update on next reboot for patch management.
- You can maintain custom repositories with Update Manager Plugin or you can simply download latest (it does this by default)
Overview of How it Works After Config
- (for server initiated discovery) Server goes to DHCP for DNS server, DNS server has OME's IP address registered
- Server gets registered in OME either via server initiated discovery or you have custom Ansible/API/other workflow that registers it in OME
- Once the server's iDRAC is registered in OME, OME launches the auto deployment process based on the server's registered service tag
- OME applies appropriate BIOS template
- This can include all the custom properties for MX chassis or storage for things like IOMs
- OME mounts ISO file via CIFs/NFS to the server
- Server boots up and your automation workflow continues from there. Kickstart, windows unattended installation, etc
Using Server Initiated Discovery
Dell has a whitepaper on server initiated discovery here.
Dell servers are factory shipped with server initiated discovery on. The way it works is the iDRAC will check DNS and if an entry for OME is present, iDRAC will automatically register itself with OME which then kicks off the automated deployment process.
See here for instructions on how to enable it. We have a YouTube video available here.
Using a Custom Discovery Workflow
If you don't use server initiated discovery you will need to build a custom harness for discovering the server. All of these ultimately leverage either iDRAC's or OMEs APIs.
- The best way to do this is with Ansible. Dell has an entire team dedicated to supporting the Ansible module. See here for the discovery module documentation.
- There is an example of how to do discovery via API with Python/PowerShell here. You will need to modify this code based on your particular framework but the script itself provides a good starting place to build from.
- Dell's API documentation is here
- RedFish is here
- OpenManage's API is here
Entirely Custom Workflow
You're on your own here. I vehemently recommend against this route. Some places to begin the process:
- Discovery with Ansible
- OME API Discovery with Python/PowerShell
- Dell's API documentation
- RedFish Documentation
- OME API Docs
- iDRAC RedFish Scripting Examples
- Modifying BIOS Attributes
- Firmware Upgrade Module
- OS Deployment Module
You will need way more than just the above. You will need to do all the job management because you will need to handle errors, you will need to do templating, you will need to create custom reporting, and a lot more.