Stellarium, a free planetarium software, is the perfect tool for teaching an eclipse. Teachers can simulate a sky from any location at any time. As our school system prepares for the total solar eclipse, we are using Stellarium to show students what they should expect to see outside. Students will be able to understand just how dark it will be and will know how to spot planets that become visible. It (along with NASA TV) also provide a fallback plan in case of cloudy weather.
For most organizations, including larger non-profits, centralized machine management is just something of a dream. These environments face two large hurdles: lack of funding and stretched support staff. I see this all of the time in education – many of our school systems do not quite reach the threshold where a product like System Center is required. Instead, these administrators are stuck in a management purgatory where they can’t find the funds for individual products and do not have the time to learn multiuse tools.
This problem has scaled in the last few years. Mobile devices and non-domain joinable hardware continues to spread. Many of these devices do not have a management system. The ones that do are completely incompatible with each other. The time strapped admin certainly does not have the resources to learn many different mobile device management systems. For a product to be successful in this environment, it must answer yes to three questions:
- Is it capable of managing traditional and mobile devices in one pane?
- Is it easy for an administrator to learn and use?
- Is it affordable over the long term?
Today, we are going to review ManageEngine’s Desktop Central and see how it stands up to our three problems.
Test 1: Managing traditional and mobile devices
If your environment is anything like mine, you have a lot of different device types to support. I have supported environments with domain-joined Windows machines, workgroup machines, iPads, Macs, Android tablets, and Ubuntu boxes. That list was just the client side of the equation!
Desktop Central’s name is a bit misleading. It supports a whole lot more than just desktops. You will find support for Windows, Apple, and Linux operating systems. This includes client and server versions. It also supports Android, iOS, and Windows mobile devices.
Even though it is not something to brag about, some organizations are still stuck with legacy machines running Windows XP, Vista, and older versions of Windows Server. I am willing to bet that this problem will be a lot worse on Jan. 15 2020 as Windows 7 will have reached end of life. A nice and surprising thing about Desktop Central is their support for end of life operating systems. Organizations that are stuck with these older machines still have full management capacity through Desktop Central.
What about management features though? This single product can handle patch management, software deployment, asset management, and configuration. Mobile Device Management can handle over the air enrollment, profile management, app deployment, and security configuration. Both devices types (traditional/mobile) have detailed auditing and reporting features. Of particular note is the integration between tools. For example, logged on user reporting ties into the remote desktop control tool. It is safe to say that Desktop Central passes our first test in spades.
Test 2: Ease of Use
First impressions can be everything. For software, that impression is formed in the installation stage. How difficult is the installation for Desktop Central? Not difficult at all. Everything is contained in a single download and the wizard is a simple straightforward process. The management portion of Desktop Central does have to be installed on a Windows OS (client or server). In the future, it would be nice to install the management components on a Linux OS as well.
Once installed, you can begin managing devices. The entire product is web based, which is awesome in my opinion. Each management component has a standardized UI and is very intuitive. Useful metrics are upfront and centered. FAQ, a Knowledge Base, and instructional videos are available at the bottom of each screen. The web-based console is also customizable through the use of widgets.
When using Desktop Central, I can’t help but to compare it against native solutions. This makes me aware of how many shortcomings those built in tools have. How would you deploy software in your environment that only comes as an executable? How would you generate a detailed list of machines and their unpatched vulnerabilities? These two common problems are clunky and difficult to solve in a native Windows environment. Group Policy Software Installation was never designed to be a full software deployment tool and WSUS does just enough to frustrate you. Both have partially built features that make you wonder if Microsoft is not trying to upsell you (GPSI User Driven Installations come to mind). Try imagining these scenarios stretched across non-Windows operating systems. Overall, Desktop Central is very easy to setup and use!
Test 3: Affordability
When purchasing software, I am reminded of a funny quote.
If SpaceX’s website can tell me the cost to put something into orbit, I shouldn’t have to call your company to get software prices.
I am happy to say that ManageEngine does not hide anything and does not force you to call them for pricing! Pound per pound, there is no doubt that Desktop Central is much cheaper than products like System Center. This is especially true if you do not want to pay for a bunch of products that you will not be using (SCVMM or SCDPM for example). ManageEngine’s pricing takes that modular methodology and runs with it! This makes it possible for you to select the exact components and pricing that you need for your environment. Prices and support options are clearly displayed. Multiple purchase methods are available (subscription based/perpetual license).
Desktop Central comes in three versions. The professional edition is designed for single sites and starts at $645. The enterprise edition is designed for many sites and starts at $795. This edition can also save organizations additional money through Windows licensing costs as it contains similar features found in the Enterprise/Education versions of Windows OS (an AppLocker substitute is the main example). The third version is for SMBs and is free for up to 25 devices. It also includes support for 25 mobile devices. It is nice to see this option available for smaller (future) customers.
Overall, Desktop Central is a win
ManageEngine’s Desktop Central passes the three big tests organizations face. It is fully featured, easy to use, and not cost prohibitive. Its modular nature enables advanced functionality and it can be integrated into other ManageEngine products. This enables some powerful combinations. Imagine things like tying in your helpdesk to your software deployment system.
Java is like a toddler. When ignored, it demands attention. We all know that it is going to act out somehow. And it probably pooped itself – I’m not checking though. For us administrators, it becomes more difficult to deploy with each version. So far, this theory has held true throughout the Java 8 release cycles. Whether you are just a release behind or very much out of date, you can use this guide to deploy the latest version of Java 8.
Getting Java 8 Ready for Deployment
Unlike some previous versions, Java 8 can be easily (and successfully) deployed with just the executable. It can also be deployed by extracting the MSI (as seen in previous Java guides). Personally, I have had better success with the executable in this release. If your deployment method relies on Group Policy, you can’t deploy the executable with Group Policy Software Installation. You will have to do one of the following instead:
- deploy the executable with a run once startup script
- deploy the executable with a run once Group Policy Preferences scheduled task
- extract, edit, and deploy the MSI
If you are using SCCM or another deployment suite, I would start with an EXE based deployment. If you see a higher failure rate, swap to the MSI. Download the offline installer from here: http://java.com/en/download/manual.jsp. The version that you deploy depends on the browser architecture version that you use. In most cases, the x86 version will suffice.
Copy the EXE to a network share where computers have read/execute. If you are deploying the MSI, launch the EXE manually now. Once the first splash screen appears, navigate to C:\Users\%USERNAME%\AppData\LocalLow\Oracle\Java\. You should see a sub folder with this JRE version and an MSI inside of that folder. Copy that MSI to your network location (you can keep both the MSI and EXE in case you swap deployments later). If you are unable to find the MSI, use What’s Changed to see where the executable is writing the MSI at.
Customizing the Java 8 EXE and MSI Installation Parameters
On a network share, create a new file named java.settings.cfg . We will eventually copy this file down to our clients. Open this file in Notepad and paste in the following:
You can add additional parameters to this configuration file if needed. For example, you may wish to add REBOOT=0 (though Java almost never requires a reboot). The parameter descriptions and available options are listed on Oracle’s Java Documentation page. Copy this configuration file to each client that will receive this Java update. The file will need to be on the client before installing this version of Java. If it isn’t, you will see this installation error: Unable to install Java. Unable to open file
There are a few ways to get this file onto your clients:
- If you are using Group Policy scripts/scheduled task, you can add a copy command to the beginning of your installation script.
- If you are using Group Policy Software Installation, you can use Group Policy File Preferences
- If you are using SCCM/other deployment suite, you can use the second method above or create a required application that installs before the main java install.
For those of you deploying the executable, wait for us at the next section as the MSI deployers have a bit more work to do.
Now that we have all of the heathen EXE deployers gone, we can talk about really cool things without them …. things like ORCA! As you contain your excitement, right click on the MSI and select Edit with Orca. If you don’t have Orca, you can download from the tools page.
Make the following changes listed below to your MSI. You can either generate a transform file (MST) or make the changes directly to the MSI. A MST is the recommended method though.
- CustomAction\installexe – change type to 3090 (this prevents the dreaded Java MSI Error 1722 from occurring)
- InstallExecuteSequence\SetSilentInstall – change condition to UILevel<=3
- The remaining settings take place under the Properties table
- Auto_Update: 0
- AutoupdateCheck: 0
- JaveUpdate: 0
- EULA: 0
- Sponsors: 0
- Web_Java_Security_Level: H (as of Java 8, H is the lowest security level available)
- WEB_ANALYTICS: 0
Deploying Java 8 with SCCM or Group Policy
Good to see you again my executable deploying friends. We will start with you all first and wrap up this article with notes for MSI deployment. When deploying the executable, I still keep all the parameters in my command line.
jre-8u101-windows-i586.exe INSTALL_SILENT=1 REMOVEOUTOFDATEJRES=1 AUTO_UPDATE=0 EULA=0 NOSTARTMENU=1 SPONSORS=0 WEB_ANALYTICS=0 WEB_JAVA=1 WEB_JAVA_SECURITY_LEVEL=H
You will also notice a few new parameters: INSTALL_SILENT and REMOVEOUTOFDATEJRES. The REMOVEOUTOFDATEJRES should get rid of any previous versions of JRE. If your software inventory still shows older versions of JRE hanging around, you can use an uninstall script like this one.
If you are deploying Java with SCCM, you can use a few different detection methods:
- You could look for the jre1.8.0_101 folder in Program Files.
- You could look for the MSI Product Code (I prefer to start my application wizard by using the MSI and then changing the installation command to whatever is needed).
- A custom script to detect the Java version (ex: you could query the version with java -version and grab that returned value).
If you are deploying the MSI, you can also use the parameters listed above. The SetSilentInstall MSI change that you made above allows the MSI to be called with the /qn switch. Your command line (if you are using a script), would look something like:
msiexec /i jre1.8.0_101.msi /qn PARAMETERS
This provides a completely silent installation. With all of that work, you can now successfully deploy the latest Java update. If you have any additional suggestions or tips, let me know in the comments below!
A few years ago, we had a horrible conficker infection. The total infected count climbed to just under 1000 machines. We couldn’t wipe machines faster than the malware could spread. Eventually, we took the entire site offline and imaged every machine.
This caused a paradigm shift for our organization. Administration was finally convinced that something had to be done with security. We were given the go ahead to do whatever was necessary to prevent a future breakout. We removed all administrative rights for users, tightened file security and the Windows firewall, and increased the level of protection provided by UAC. The biggest change though was the implementation of AppLocker with whitelisting.
AppLocker with a Whitelist
With the release of Windows 7, Microsoft essentially replaced Software Restriction Policies with the introduction of AppLocker. If you have ever used Software Restriction Policies, you fully understand the inherit limitations. While it was easy to block or allow specific applications, creating global whitelists or global blacklists was nearly impossible. Further, these policies lack flexibility in who they applied to or how they were deployed. AppLocker, available in Windows 7/8 Enterprise, addressed these limitations and added some essential features.
What is so important about a Whitelist? With a traditional antivirus, malware is detected through definition files. Malicious software is caught when it is known or when it behaves a certain way. Blacklists are always limited because malware constantly changes. In terms of security, the real power of AppLocker rests in the ability to create a whitelist. A whitelist comprises of known trusted software. Anything not on the whitelist is not allowed to run. Suddenly, you no longer have to worry about updating definitions or the latest threat! If it wasn’t trusted before, it won’t run now.
How to Setup AppLocker in Whitelist Mode
Once again, we are going to turn to Group Policy. Create a new GPO named AppLocker Configuration. We will store our domain’s general AppLocker settings in this GPO. Be sure that this GPO is not linked to an OU at this time. Edit the GPO and navigate to Computer Configuration/Windows Settings/Security Settings/System Services. Select the Application Identity service and set it to Automatic. If you are not on a Server OS (2008 R2+) or an Enterprise Client OS, you won’t see this service.
After enabling the service, navigate down to the Application Control Policies node and expand AppLocker. The OS you edit the GPO from will determine what AppLocker can control. If possible, edit this GPO from a Windows 8/Server 2012 machine in order to get the most out of AppLocker. As a best practice, you should always use the latest GPMC (and RSAT tools) available.
With AppLocker, we can control five types of files: executables (.exe, .com); a variety of scripts (.bat, .cmd, .js, .ps1, .vbs); DLLs files (optional); Modern Apps (.appx) and MSIs (or MSPs). For right now, we are only concerned with executables and scripts as they comprise the bulk of threats.
Our first step is to configure how AppLocker will run. Select the main AppLocker node and then choose Configure Rule Enforcement. We are going to select the enforcement options for Executables and Scripts. Because this is a test environment, we are going to leave Enforce Rules as the default method. If this was a production environment and if you were unsure if any applications are used outside the default rule locations, you would want to change this to Audit Only or do a phased rollout.
Our next step is to configure our default (white list rules). Select the Executable Rules node – right click and choose Create Default Rules.
You should now have three new rules. Before continuing, select the Scripts Rules node and generate the default rules for that node as well. It is extremely important for clients to have the default rules applied to them. If not, Windows won’t even come up to a logon screen!*
Notice that the Condition column for each rule specifies “Path”. Let’s break down a rule. Take the default rule “All files located in the Program Files folder”. The rule literally states “Allow Everyone to Run Any Executable (.EXE/.COM) that has a location of C:\Program Files\* (and if needed, C:\Program Files (x86)\*). When your environment deploys software centrally, you can see how simple AppLocker is to maintain.
Creating a New AppLocker Exclusion Rule
Let’s say that you have a legacy software that installs to the root of a drive (C:\). With AppLocker enabled, it obviously will not be allowed to run. With just the default rules, the legacy application must exist in either C:\Windows\* or C:\Program Files\*. For applications that fall outside the scope of the default rules, we will need to create a specific application exclusion rule.
Creating a new rule is easy. As an example, we are going to create a new folder in root of C:\. We will then copy notepad.exe to this folder and use it as our legacy application. Once we have linked our GPO and restarted our test machine, we can log in as a standard user to test AppLocker. When you try to launch the legacy application, you should receive this error message:
This error is also logged in Event Viewer under Application and Services Log/Microsoft/Windows/AppLocker. Let’s now create an exception for the legacy app. Right click on Executable Rules and select Automatically Generate Rules. While you can manually create rules by selecting Create New Rule, rules create automatically will always adhere to Microsoft’s best practices.
Automatically Generate Rules button will launch a Rule wizard. In the wizard, change the browse location to the C:\LegacyApp folder and select Next. You can now choose the rule type. Rules can be one of three types: Certificate, Hash, or Path rule. When creating a rule, you should always try to create a digitally signed (certificate) rule first.
If the files are not signed, you will have to choose between a hash or path rule. You will generally choose a hash rule if the executable is rarely updated. Because a hash rule only applies to a very specific version of a file, updating a program will require you to also update the hash rule. A path rule is your final option. It should normally be a last resort and should never apply in a folder where a standard user can write to.
Knowing the rule types, we can select the default rule type in the Rule wizard. Notepad is a signed file so a certification rule will be created. If it wasn’t signed, a hash rule would have been created. We can then press Next and finally create our rule.
Your executable rule list should now list your new rule. After running a Group Policy Update on our test machine, our legacy application will now run. Rules are cumulative. You can add them to specific GPOs. Any applied to a client will simply stack to build an AppLocker exclusion list. You can use GPResult on the client to view applied rules.
AppLocker is an incredibly powerful security tool. By implicitly denying all untrusted applications, you can secure your organization against the unknown. Users are unable to download all of the junk that causes most of their problems (toolbars, coupon clippers, weather stuff, etc…). Though it does require a bit of IT overhead, never having a virus outbreak again is an awesome benefit!
If you use AppLocker, what tricks make it easier to manage? If you aren’t using AppLocker, what is stopping you from doing so?
*Fun fact – I once spent an entire morning troubleshooting this particular problem!
Google Chrome for Work is a simple enterprise wide deployment of Google Chrome. The installation for Chrome is an MSI. It can be silently deployment with Group Policy Software Installation, SCCM, etc. Controlling updates, home pages, plugins and other settings can be done with the Google Chrome ADMX templates. Basically, Google has finally addressed the Enterprise issues with Chrome. In this guide, we will deploy Google Chrome for Work with Group Policy and configure our user settings.
Download the Google Chrome MSI and Google ADMX templates
Grab the following downloads:
Save the Google Chrome MSI to a network share. Domain computers will need to have read/execute to the share and folder.
You will need to extract the contents of the Google Chrome ADMX into your Group Policy Central Store or into your local policy definitions folder (C:\windows\PolicyDefinitions). The Google Update ADM is needed to control the Google Update service which provides update for Chrome and other Google products. As far as I know, there isn’t an ADMX available for this product.
Create the Google Chrome GPO and Groups
Create a new GPO named APP_Google Chrome. Create a security group with the same name and scope your GPO to this security group. Edit your GPO and navigate to Computer Configuration/Policies/Software Settings/Software installation. Right click on software installation and select new package. Browse to the Google Chrome MSI. Be sure to browse to the network share (\\Server\share\folder\google chrome.msi). Do not use a local path (C:\Software\google chrome.msi) when deploying applications. If you have trouble deploying this MSI, see this troubleshooting guide.
If your Google Chrome ADMX files were correctly placed in the Central Store/Policy Definitions folder, you should now see a Google folder under Computer Configuration/Policies/Administrative Templates. When configuring Chrome settings with Group Policy, I prefer to use the first option (highlighted below). This option enforces the settings that you configure instead of treating them like preferences.
The four settings that I configure are:
- Allow running plugins that are outdated: Enabled
- Set Chrome as Default Browser: Disabled
- Startup pages\Action on startup: Enabled – open a list of URLs
- Startup pages\URLS to open on startup: Enabled – homepage URL
Disable Google Update for Chrome with Group Policy
You will likely want to configure the automatic update service for Google Chrome. Right click on Administrative Templates and select Add/Remove templates. Click Add and browse to your Google Update ADM (downloaded from above). Under Classic Administrative Templates, you should now see Google. Select Google Chrome under Classic Administrative Templates/Google/Google Update/Applications.
To disable updates, select Update policy override and enable it. Change the policy option to Updates disabled. As a test, I am seeing if automatic silent updates only will allow standard users to receive updated applications without administrative permissions. More to come on that experiment.