Private corporate batches, live online cohorts and 1-on-1 mentoring in Windows package management at fleet scale — choco install and upgrade, custom packages, internalised sources and unattended provisioning — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Chocolatey as fleet tooling rather than as a desktop convenience: the full command surface and its configuration model, sources and proxies, pinning and upgrade behaviour, then package authoring with nuspec and PowerShell install scripts, package parameters and templates, and the internalisation work that removes any dependency on the public gallery. Sessions run against real installers on real Windows hosts, including the failures — checksum mismatches, silent-install arguments that are not silent, and upgrades that leave two versions installed.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Chocolatey that means a trainer who has run it in production — Windows package management at fleet scale — choco install and upgrade, custom packages, internalised sources and unattended provisioning — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Chocolatey batchChocolatey is a package manager for Windows. It brings the model Linux administrators take for granted — a named, versioned package that can be installed, upgraded, pinned and removed by a single command — to a platform whose native software distribution has historically been an installer downloaded from a vendor website and clicked through by a human.
A Chocolatey package is built on the NuGet package format: a nuspec manifest describing identity, version and dependencies, plus PowerShell scripts that do the actual work. The install script typically calls a helper such as Install-ChocolateyPackage or Install-ChocolateyInstallPackage, which downloads an MSI or EXE, verifies its checksum and runs it with the correct silent-install arguments. Because the payload is PowerShell rather than a fixed file layout, Chocolatey can wrap installers it did not author — which is exactly why it works with the existing Windows software estate.
That design has two consequences worth understanding before adopting it. Most community packages on the public gallery download binaries from vendor sites at install time rather than embedding them, which means availability and distribution rights sit outside your control; recompiling or internalising packages so the binaries live on your own infrastructure is the standard answer for any serious deployment. And because packages execute PowerShell with administrative rights, package provenance and source control matter as much as the packages themselves.
Windows fleets are managed like Linux fleets now, or they are managed badly. Configuration management, golden-image pipelines, developer workstation provisioning and container base images all need software installation to be a declarative, repeatable, unattended operation. Clicking through an installer is not that, and neither is a share full of setup executables and a runbook.
Chocolatey has become the de facto answer because it meets the platform where it is. It wraps the installers vendors already ship, integrates with Ansible, Puppet, DSC and Intune, and works identically on a developer laptop, a build agent and a Windows container. Teams adopting it typically go through the same arc: first a few choco install commands, then a package list checked into source control, then the realisation that depending on the public gallery for production is not acceptable, and finally an internal feed of internalised packages.
The skills gap sits at that third step. Consuming public packages is easy. Authoring packages for internal software, internalising third-party ones so they no longer reach out to the internet, maintaining them across vendor version changes and distributing them from a feed you control is where teams stall — and it is what a fleet of any size actually requires.
The problem Windows software distribution has and how a package manager addresses it. What Chocolatey is built on, how it relates to NuGet and PowerShell, installing and removing it cleanly, and the directory and configuration layout that everything afterwards depends on.
Topics: Why Chocolatey? — the case against installer-and-runbook distribution · Using Chocolatey — the model, the vocabulary and what a package really is · Installing Chocolatey — bootstrap script, offline install and non-default locations · Uninstalling Chocolatey and what it leaves behind · Getting Started — first commands and confirming the install is healthy · The lib, bin and config directory layout, and shims
The commands engineers use daily and the behaviour behind them. Finding software, installing specific versions, understanding what upgrade does when a vendor changes their installer, removing packages, and where the graphical interface fits for less technical users.
Topics: Use Chocolatey to install applications · Find apps with Chocolatey Gallery — searching, and judging package quality · Work with versions — installing, side-by-side and version selection · Use Chocolatey to uninstall applications, and the packages that do not remove cleanly · Use the Chocolatey GUI application · Reading package install output and locating the logs
The full command surface, taught as a working reference. Every command has behaviour that only shows up at scale — exit codes that CI reads, arguments that change silently between versions, and the difference between what a command reports and what it did.
Topics: Command Reference — the shape of the CLI and global options · Passing args to choco — install arguments versus package parameters · Complete Reference — where to find authoritative behaviour per command · List / Search — local versus remote listing and output formats · Info — inspecting a package before installing it · Install — versions, sources, checksums and force behaviour · Pin — freezing a package against upgrades and when that is correct · Outdated — reading it accurately, including false positives · Upgrades — upgrade all, exclusions and upgrade notification handling · Uninstall — arguments, removal scripts and residue · Exit codes and how CI should interpret them
Making Chocolatey behave identically everywhere. The configuration file and the commands that edit it, source priority and authentication, feature flags that change global behaviour, and the network-level settings that decide whether this works at all behind a corporate proxy.
Topics: Config — the configuration file, settings and precedence · Source / Sources — adding, prioritising, disabling and authenticating sources · Feature — feature flags and the ones worth changing deliberately · Download — fetching packages without installing them · Use Chocolatey w/Proxy Server — proxy configuration and bypass lists · Change Download Cache Location aka Don't use TEMP for downloads · Checksum enforcement and why disabling it is a decision, not a workaround
Moving from one machine to many. Declarative package manifests, running without prompts or interactive input, controlling whether package scripts execute, and driving Chocolatey from configuration management and image build pipelines.
Topics: Batch installs with Chocolatey config files — the packages.config manifest · Install/Upgrade a Package w/out running install scripts · Unattended operation: confirmation, timeouts and non-interactive execution · Driving Chocolatey from Ansible, Puppet, DSC and Group Policy · Chocolatey in image pipelines and Windows containers · Idempotency: making a repeated run a no-op · Reporting installed state back for compliance
Authoring your own. The package structure, the nuspec manifest, the PowerShell install and uninstall scripts, and the legal question that decides how most organisations package third-party software: whether you may redistribute the binary at all.
Topics: Packages — structure, layout and the NuGet format underneath · Creating packages — choco new, nuspec fields and versioning · chocolateyInstall.ps1 and chocolateyUninstall.ps1 · Wrapping MSI and EXE installers with correct silent arguments · Checksums, and why every download needs one · Keep in Mind Distribution Rights — embedded versus downloaded payloads · Testing a package locally before it reaches a feed
The API available inside a package script and the mechanisms that stop a package library becoming forty inconsistent one-offs. Helper functions, environment variables, user-supplied parameters, and templates that encode your organisation's conventions.
Topics: Package Function and Variable Reference — the helper library and what each function guarantees · Parse Package Parameters — accepting and validating user-supplied options · Environment variables available during package execution · Mount Iso and packaging software distributed as disc images · Create Custom Package Templates for consistent internal packages · Shims, ignore files and controlling what lands on PATH · Error handling and making a failed install fail loudly
The step that makes Chocolatey production-grade. Removing the runtime dependency on vendor download URLs by embedding or relocating binaries, then hosting the results on a feed you control — including fully offline and air-gapped estates.
Topics: Manually Recompile Packages, Embedding/Internalizing Remote Resources · Why depending on vendor download URLs is a production risk · Hosting an internal feed: file share, repository manager or gallery · Mirroring and offline or air-gapped distribution · Package signing and source trust · Automating internalisation as vendors publish new versions · Feed retention, promotion and rollback
Packages are not finished when they are published. Keeping them current as vendors release, deciding what to fix locally versus upstream, taking on maintainership responsibly, and retiring packages without breaking the machines that still reference them.
Topics: Outdated packages? Triage process — deciding what is actually stale · Request Package Fixes/Updates through the community process · Request Package — asking for something that does not exist yet · Maintain Packages for My Software as a vendor or internal owner · Become a Maintainer — expectations and review process · Take Over Package Maintenance Exclusively when a package is abandoned · Deprecate a Package and migrating consumers off it · Automated version detection and update pipelines
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a machine from bare Windows to a full developer or build-agent software set using only a checked-in packages manifest, with no interactive input at any point.
Configure proxy settings, cache location, features and sources so a locked-down host installs successfully and can no longer reach the public gallery.
Package a third-party MSI with silent arguments, checksum verification and a working uninstall, then add package parameters so consumers can configure it.
Internalise a community package so its binaries are embedded or relocated, publish it to an internal feed, and install it on a host with no outbound access.
Build a custom package template encoding your naming, logging and error-handling conventions, then generate two packages from it and compare them.
Deliver the full path: internal feed, internalised third-party packages, authored internal packages, unattended provisioning and a documented maintenance process.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.