Ninite has long been my number one tool for deploying, updating and removing popular 3rd party applications… I especially enjoy the feeling of removing Flash and Java from any where I can get my hands on 🙂
Up until now, Ninite has been completely agentless. You get a simple light-weight .exe which you can either run by double clicking or by using switches in the CLI (NinitePro.exe).
To automate the process of deploying or updating applications you previously had to script something together and schedule the .exe to run at a schedule. I don’t mean to make it sound like scripting it to make it work in your environment is difficult – it really isn’t but sometimes it can be tricky to implement for machines that are either not on the domain or simply not on the premises to receive those updates.
Please note that these new features are designed for business/enterprise environments so only available for Ninite Pro users.
Ninite Appsheet
Ninite Appsheet is like NinitePro.exe on steroids. Here’s why…
- It’s browser based. Yes, you can now add, remove and patch your machines via a web browser. From anywhere.
- It presents a very intuitive interface. You can instantly see an overview of your estate in the Overview tab
- Easily patch a single application on all machines or all applications on a single machine – the flexibility to patch your machines makes life a lot easier here
- Policies!!! I’m really excited about this one. You now have the ability to set policies so that updates are checked for and applied hourly. You can also set exceptions here so don’t worry guys, that finance application will still have access to Java 6 (kill me now).
What I really like about the new management interface is that because it is so easy to use I feel confident giving my colleagues on the service desk staff access to run wild with it.
Below I will briefly go over the installation of the agent and then move on to summarise the different tabs in the Ninite Appsheet web interface.
Installing the Agent and How it Works
In typical Ninite fashion, the agent is only a few hundred Kilobytes. Installation literally takes seconds and no reboot is necessary.
There are a number of ways you can install the agent:
- There is a .msi available so you can script something together (GPO, SCCM, PDQ Deploy, MDT, etc)
- You can use the Ninite agent .exe which you’d use if you want to manually install it on a machine (non-domain joined for example)
- Lastly you can use a special Ninite network installer .exe which is basically exactly the same as the NinitePro.exe except it only pushes out the Ninite Agent
The agent does the following:
- Installs a Service called Ninite Agent which runs as Local System
- Starts a process called NiniteAgent.exe
- Establishes a TLS tunnel to remote.ninite.com
- Sends the necessary information over the established tunnel so that Ninite can know which software can and can’t be installed (compatability, etc). For example the running OS version, applications it can support, version numbers, etc.
You can view this information in the Appsheet interface.
Logging in to Appsheet
You can access the Appsheet portal with any modern web browser. The interface is very intuitive and easy to use so it’ll only take you a few minutes to get the hang of things.
The URL to access Appsheet is: https://ninite.com/appsheet
You’ll be taken to the Overview tab as soon as you log-in. Here you’ll see a summary of how many machines have the Ninite Agent installed and which applications need updating.
Apps
Here is where you’ll be doing most of your work; installing, updating, re-installing and removing applications is done from this tab.
See the options in the top right corner? Here you can select only #online machines with installed applications… or #online machines with outdated applications only.
This is what I have done in my example below – here you can see a subset of #online machines with out of date applications. Ignore the thunderbolt and padlock icons for the time being – I’ll explain those later.
Kill + Retry
Kill + Retry is a cool addition that the Ninite agent can perform which the agentless approach cannot do (without additional scripting); essentially what it can do is kill applications that are preventing them from being updated (think applications like Skype which start on boot) then retry the update.
Machine Details
The machine details tab allows you to assign policies to machines (we’ll come on to policies next), add tags to machines, delete machines from the dashboard and uninstall agents from machines remotely.
It also shows you some additional information such as disk utilisation, whether there is an anti-virus installed on the machine and if it’s enabled and up-to-date.
Policies
This is where you can get really clever and apply policies to your estate. By doing this you can be almost virtually hands off Ninite and let it handle itself.
Take the policy below as an example.
- Policy Name: This can be anything you desire. Give it a sensible name.
- Update Policy: Manual means “don’t touch anything – I’ll handle it all myself”. Automatic means “update everything please” and Locked means “stop me from accidentally updating/removing this app”
- Disable built-in updater and update notifications: I always enable this as I don’t want my users to be notified of updates – IT will handle everything (I have an exception for Chrome though)
- Disable desktop shortcuts: I always enable this too – I don’t want to clutter up user’s Desktops’… if they want a shortcut they can make one.
- App Exceptions: Remember that 10 year old finance app still using Java 6? Yeah, you can set an exception here so that it stays locked.
I also have an exception for Chrome for two reasons – (i) Chrome is pretty good and handling itself without causing disruptions and (ii) by disabling the updater for Chrome you may get issues manually updating Chrome – I got the message “Chrome Updates are disabled by your Administrator” if I disabled the Chrome updater via Ninite without an exception.
To actually apply policies you will need to do this in the Machine details tab.
How Secure is it?
It all sounds well and good but can we trust the agent? After all it runs as the local system account and runs executables downloaded off the internet. I also had these concerns and directed them at the team over at Ninite and this is what they had to say:
“Right now the agent’s actions are limited to basically what Ninite Pro itself can do. So there’s no agent command or anything to do arbitrary downloads or run arbitrary .exes. The commands are just like ‘install Firefox’, ‘uninstall Skype'”.
You can also see some more information around security on this page @ https://ninite.com/security/
In addition, two factor authentication is coming soon to prevent someone who has obtained your account credentials from wreaking havoc on your systems – What could be worse than someone logging in to your Ninite account and mass installing Flash and Java 6 on everything… *shudder*.
I hope that gives a good overview of the new features – I think it’s definitely a big step forward in that it will allow administrators to more easily keep systems patched; in turn you keep your environment safer from potential vulnerabilities and threats from these 3rd party applications.
4 replies on “Ninite Appsheet – Patching Just Got Easier”
How do we deploy the Network Agent like we would with apps via Ninite Pro? I created a test batch to deploy via GPO like this:
\\server\netapps\ninite\Niniteagentnet.exe /cachepath “\\server\netapps\ninite\NiniteDownloads\files” /silent \\server\netapps\ninite\reports\%computername%.txt /select Agent /disableshortcuts /disableautoupdate
Hey,
You can download the agent .msi or .exe – you should be able to GPO them (we use PDQ to deploy the .exe) like you would with any other .msi. You can find the different downloads in the Appsheets ‘overview’ tab –> download agent –> show more options. Hope that helps.
Fantastic! A couple of feature request to consider that would be helpful to MSP’s:
It would be great if we could assign a policy during the installation – “NiniteAgentInstaller.exe /silent /policy PolicyXYZ”
A log file, or event log entries detailing updates done.
Hello Eddy,
I have sent Ninite similar feedback (I asked for an option to set a ‘default’ policy which applies to all new machines by default) but I would suggest you send them feedback within Appsheet – they respond to them fairly quick too!