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.
Let’s say that you have a GPO that is scoped to a specific security group. If you add a computer to this security group, you would normally need to restart in order for the computer to see that it is now a member of this group. To bypass this, you can delete the system’s Kerberos ticket and run GPUpdate. The computer will magically see its new group membership without a restart.
To do this, run the following from an elevated command prompt:
klist -li 0x3e7 purge
The system account on every computer (no matter the OS) has the same low part of the locally unique identifier (LUID). In the command above, that input is 0x3E7. To run this command remotely, you can use something like the Right Click Tools in SCCM or PSExec. After running the command above, be sure to start a gpupdate.
And on a completely unrelated note – I recently helped an organization after they had a complete AD meltdown. Unfortunately, they had did not have a DR plan in place. If you haven’t, spend a few hours this week and create/review your plan. Ensure you have backups and that you follow Microsoft’s best practices. If you don’t know where to start, see this link or contact me.
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!
Every administrator is familiar with the dreaded No Logon Servers Available error message. While the symptoms are the same as a broken trust relationship, the solution is completely different. Simply stated, find out where the network broke to fix the No Logon Servers Available error. Wireless devices make this problem a bit more difficult to fix. Wireless devices without physical NICs can make fixing the problem even harder. Adding a backup wireless network can help you fix these issues faster (or even automatically)!
Creating a backup wireless network involves two main steps. First, you have to configure your wireless infrastructure to broadcast and allow access to this secondary connection. These steps are very specific to the network devices that you have. The guidance in this section will be high-level. The second phase of configuration is making your clients aware that a backup connection is available. This is done in Group Policy and these steps will be specific to Windows Vista+ machines.