Infrastructure-as-code, declarative management, desired state configuration, call it what you want, at the end of the day we’re talking about making rules.
A good deployment rule needs to know who, what, when, where and why
Who needs it?
People use software, not computers
Traditional software deployment tools focus on deploying software to computers.
If your client has ever given you a list of people that need a piece of software, you know how painful it is to translate that into a list of computers.
Immy tracks what computers people use, allowing you to select People or Groups of people, and know instantly what machines will receive the software.
What is it?
You can deploy Software, Settings, Monitors, Patches, Feature Updates, VPN Profiles, Power Settings, and more. If PowerShell can do it, Immy can do it.
When should they get it?
Schedule deployment to happen after hours, notifying the person ahead of time.
Where does it come from?
Sometimes you luck out and an existing repository will already have the software you are trying to deploy.
Rather than having to find out yourself, Immy’s search bar will instantly search Chocolatey, Ninite, the Immy Global Repository and your Local Repository. Immy will install Chocolatey and Ninite automatically.
Why should they have it?
Is it part of their agreement with you?
Is it part of their Microsoft 365 Plan?
Is it because they are a member of a certain Group/Team?
We thought about the most common sources of truth and built integrations to them.
These same rules can be used to remove software.
Maybe you should make a rule to remove your competitor’s ScreenConnect client…