Prevent package reinstall when migrating from Avalanche 4.8 to Avalanche 6.1

When devices are migrated from Avalanche 4.8 to 6.1 it is likely that some or all of the packages will reinstall. This is not an ideal scenario if you have 1000s of devices reinstall apps.

To overcome this issue, one way is to Orphan the packages with no packages available for them to download in Avalanche 6.1. To do this lets look at the following example:

Scenario – Migrate Motorola MC3100 devices which have Telnet installed, from Avalanche 4.8 to Avalanche 6.1 without reinstalling Telnet or any other apps. If the device is rebuilt then the required apps should install.

Solution –

1.       Create 2 folders for the devices – one for the migrated devices and one for devices to be rebuilt in future

Migrated Devices folder will have the following selection criteria.

ModelName = MOTOMC3100 AND package.TN403000="OK"

This just means that if the device has Telnet installed then the device gets assigned to this folder. This folder will have no Profiles and hence no packages assigned. When devices with Telnet installed are migrated to Avalanche 6.1 they will fall in this selection criteria and not install/reinstall any packages. All the existing packages on the device will show “Orphaned”.

                                                                            

Rebuild Devices folder will have the following selection criteria:

ModelName = MOTOMC3100 AND (!(package.TN403000="OK" ))

This means that for a MC3100 device which does not have Telnet installed it will get assigned to this folder. This folder will have the necessary profiles and packages assigned for the device type. When a device is rebuilt it will not have Telnet installed and will fall in this folder and install the rest of its packages.

It is not necessary to use Telnet, I have just used it as an example, you can use any other package by replacing TN403000 in the selection criteria.

Incorrect folder selection criteria in Avalanche 6.1

Issue - In Avalanche 6.1 when a device is rebuilt or reconfigured with a different Folder selection criteria it does not get removed from the previous folder and does not get reassigned to the new folder. It will even install packages that are assigned to the old folder where it initially populated and not the new folder it is meant to populate in.

What that means is that a device build for Folder ABC for example cannot be reconfigured for another folder say XYZ unless it is first deleted prior to reconfiguration. It will also install the profile from its previous location. 

Resolution - Thanks to Christian Blunschi at Wavelink in Melbourne found the resolution very quickly. 

1. Go to Profiles - My Enterprise and select Default Mobile Device Server Profile.

2. Select the profile and click Edit 

3. Under Device Folder Assignment tick "Dynamic by selection criteria". 

This will allow the devices to dynamically get assigned based on changes to its selection criteria. 

4. Click on Close. 

5. Deploy the changes. 

Avalanche 6.1 Web console

With Avalanche 6.x Wavelink have discontinued the use of Java console and provide a Web console. This is great since it does not require a separate installation on the Administrator's PC and also for large organisation where multiple users login to the console, the console does not need to be packaged. 

However, I have found the response of the web console to be very sluggish sometimes even to the point where it becomes frustrating. Let me provide an example - the other day I was working on creating multiple folders under a region. Then I wanted to sort them out alphabetically using the Up/Down arrow, so I selected one folder and clicked up arrow. Nothing happened, so naturally I clicked the up arrow again eventually after about 10 seconds the folder moved up 2 spots. Then I had to click the down arrow and again, no response...and so on. 

I wish in future releases Wavelink look at returning the java console atleast it provides the serious administrator with the option to have a locally installed console. 

Avalanche 6.1 Mobile Device Server installation and configuration

A few days ago I wrote the following blog on designing the strategy for Mobile Device Servers in an Avalanche 6.1 environment
Mobile Device Servers design

Let us now look at the installation of Device servers and how to connect them to an existing Avalanche 6.1 installation. 

First off the Device server only installation file is required. The name of the file is WavelinkMDS_windows-x64_6_1_103_53-508

Once the file is obtained, copy it to a local directory on the server which needs to perform the Device Server role. 

The actual installation is very straight forward. A few steps need to be performed on the Enterprise server after this installation to complete the setup. 

PART 1 

1. On the server go to the location which contains the installation exe and double click to launch the installation. 
2 . Click on Run to run the file . 

3. Installation will commence preparing 

4. Click on Next to setup. 

5. Change destination folder if required and click Next

6. Select Start Menu Folder

7. At the next screen enter the Avalanche Address and Site Identifier. 

Avalanche Address: This is the IP address or hostname of the Avalanche Enterprise Server. 

Site Identifier: This value can be customised. This is the name that the Mobile Device Server will use to register in Avalanche (on the Enterprise server) . I do not think this name can be changed later. The name of the Device Server itself can be changed in the console. Will get to it a bit later. 

8. Installation will now commence

9. Click Finish when installation is complete. 

This completes the installation of the DServer but the setup of the Infrastructure is not complete yet. There are a few more steps that need to be completed. 

Login to the Enterprise server or the Avalanche console and you will see that the new Device Server will be in the Unassigned Server Location. This needs to be moved to the correct location. 

PART 2

There are a few rules to keep in mind before starting to move servers and creating regions. 

1. Each region can have only one Device Server associated. 

2. If you try and move a Device Server to a region which already has another device server associated will throw an error - A Device server of this type already exists in this region.

3. When a device server is installed using the combined  installation file (Wavelink-Avalanche_windows-x64_6_1_103_53-599.exe) then by default the Device server will be installed under My Enterprise. If you plan to install multiple Device Servers it is a good idea to create a region for this Device Server and move it from under My Enterprise to its correct region. If the plan is for a centralised model, then  the device server can stay under My Enterprise.

4. If you move a Device server from one region to another all the devices connected to this Dserver will move to the Unassigned Devices folder.

However the devices move to Unassigned Devices folder under the new Region and not the Unassigned folder under My Enterprise. 

5. When device servers are moved across regions they need to be Deployed again. 

PART 3

Keeping the above points in mind lets have a look at how to configure the Device servers in the console. 

Check under the Unassigned Server Locations and you will find all the recently installed device servers 

The following steps will show how to create a region and assign the new Device server to a new region. 

1. Create a Root Level region under My Enterprise and lets call it 'My Organisation'.

This new region will need to be deployed. Click on Needs Deployment and then select Deploy Now and Finish to complete the deployment. 

2. Go back to Inventory - Unassigned Server Locations and click on the Device Server, click on Move. 

3. Select the region created in Step 1 above. 

Renaming Device Servers

1.  Click on the Device Server to be renamed.

2.  Click Edit and change the Name to the required Dserver. Also a good idea to check the Time zone in the same Server Details screen.

3. Provide the IP Address of the Dserver being changed. Otherwise you will get this 

4. Click Save

5. Note that changing the Device Server name does not change the Site Identifier that was specified during the installation of the Device Server.

6. Note – when changing the name of the Device server for a centralised model, the server address can be local host

PART 4 

      Once the Regions, Servernames and Device Server moves have been sorted out click on Inventory and it should look something like this: 

The above shows two regions called My Organisation and Another Business Unit each with its own Device Server.

1. Click on both the Dservers and click on Deploy

2. Click on Needs Deployment on the top right corner and select deploy now. 

3. The servers will start synchronising. 

4. When the synchronisation has completed the Deployment status will change to 'Up-To-Date'

Deleting a Region with an associated Device server

What happens if you delete a region? Lets say accidently. What happens to the Device server and the devices associated to that region?

-          First the system will warn that there is a Device Server associated with the Region. You will have to click on Delete to confirm

The Device Server along with the Devices will be moved to Deleted server Locations.

Note – when a Device is in the deleted server locations, the Deployment state of the Device server stays as Up-to-date

To reinstate, recreate the Region and move the Device Server to the new region following the steps above. 

Avalanche 6.1 AD integrated Login

It is bit unclear reading the Avalanche help instructions how to get a AD user to login to Avalanche 6.1 premise version and assign the permissions for the user.

I have found the following worked for me:

1.  Provide the LDAP server name

·         Go to Tools – System Settings – Authentication Options

·         Select the authentication as LDAP

·         Provide details for the LDAP server

    2. Once the LDAP server is provided, logout as the admin user and login as the AD user you want to add. Provide both Domain and login.

     3. This process will create a Normal user account for the AD user in Avalanche.

     4. Logout as the AD user and log back in as the administrator.

     5. Go to Tools – System Users. Here you will find the new user as Normal user.

    6. Click on the user to edit and directly assign permissions to the users.  

                OR

    7.  Create a new group by going to Tools – System Users – Add – User Group

·         Provide Group Name

·         Provide Description

·         Select whether users in the group will be Normal Users or Administrators

·         Select which location the group will have access to. Default is My Enterprise.

·         From the Group User List select the users you want to add to the group.

·         Set permissions for the members in the group – Profile, Inventory, Rule and Other.

·         Click Save. 

Avalanche 6.1 - Design decicion - Placement and Number of Device Servers

When designing an Avalanche infrastructure the question always arises on how many Mobile Devices servers to install and what logic should be applied to determine the number and location of the Device servers. This is specially true if either a new Avalanche environment is being installed or an upgrade is performed in the form of a side by side migration. Side by side migration is where the previous installation of Avalanche is not upgraded but a new Avalanche 6.1 infrastructure is installed along side the existing installation and the devices are migrated from the old infrastructure to the new infrastructure. How the devices can be migrated between environments can form part of another article.

There are two models possible:
1. Centralised model and
2. Distributed model

Lets look at both these models in bit more detail and the scenarios where these can be typically implemented.

Centralised model - All of the Avalanche services are installed on a single computer. This type of configuration is typically used for smaller implementations of under 5000 devices connecting to the Device server. A good example of this is a lab environment or development environment. If there are no specific business requirements or bandwidth considerations this model can also be used. Two configurations are possible with the centralised model depending on whether smart (Android/iOS) devices are present in the environment.

i) Enterprise Server with Mobile Device Server and Smart Device Server - used for implementations of under 1500 devices.  

ii) Enterprise Server with Mobile Device Server - used where there are no smart devices to be managed, and the number of AIDC devices are under 5000.

Distributed Model - In a distributed model the Device servers are installed on different servers. Depending on the server specs (CPU,RAM and Disk Space) the maximum number of devices that can connect to a device server is 10000.
There are several requirements which can dictate the number and placement of Device servers apart from the number of devices connecting to the Device server. Lets look at some possible scenarios.
i) Bandwidth requirements - for low bandwidth sites it is advantageous to have a Device server on site rather then in a central data centre. That way the devices connect to local server to download packages.
ii) Business Requirements - If a business has several business sections it may make sense to install a Device server for each business. The devices for each business connect to their respective Device server.
iii) Device Types - If several different types of devices are present in the environment it may make sense to split device servers per model. Example - a device server for printer and a device server for scanners.
iv) Geo location - One other option is to create a Mobile Device Server in each state of the country.

Note - there can be multiple device servers but only one smart device server.
 

Avalanche 6.1 bug fix - Zebra printers not reporting in Avalanche

Earlier I had reported an issue with Avalanche 6.0 whereby the Zebra printers are not populated in Avalanche.

Zebra printers not reporting in Avalanche

With the release of Avalanche 6.1 this bug has been resolved and the printers now populate under the Unassigned Devices folder.

Zebra QLn320 Printer known bug

A bug has been identified with the Zebra QLn320 printers whereby the MAC address becomes 00:00:00:00:00:00

When this happens the printer is not able to connect on wifi. 

The only fix is to send the printer back to Zebra for hardware repairs. Re flashing the firmware will not resolve this issue. 

Affected firmware - V68.19.6Z

Zebra have confirmed they will provided a fix with a new firmware update by end of Dec 2014. 

Avalanche server patching

The avalanche MDM is installed on Windows Server environment which is generally administered by a separate Windows team in large enterprises. 

There are regular updates and patches applied to Windows server and as Avalanche application owners on the servers we are tasked with making sure the Avalanche environment is "healthy" after these patching.

I have documented below a cheat sheet of what needs to be checked after the patching schedule to make sure Avalanche is running as expected. These steps if documented can be performed by Support personnel and does not need an Avalanche expert. 

Depending on the organisational setup modify the below with location of your files and installs. 

1. Before the patching commences make sure there is a recent backup of the Avalanche DB. 

2. Patching can commence. 

3. After patching check that the Wavelink and Landesk services on the Enterprise as well as Device server are       Started. 

4. In the Avalanche console under inventory check that the devices are checking in with last contact time to be       very recent. 
    In Avalanche 6 this can be checked in the Inventory tab. 
    Click on the last contact column heading to sort out in Descending order. 

5. I also recommend having a test device connected to the environment before the patching. After patching of         the server, from Enabler on the device perform a software update and ensure the device successfully                 connects to Avalanche. 

6. Another test I would also recommend to do is have a Test profile in Avalanche always available and call it           Server Patching. This profile can have one test package with a simple text file to be deployed to \Temp folder     on the device. 
    After server patching deploy the package to the test device we had connected at Step 5. Check the device         receives the text file in the \Temp folder. 

Windows Phone 8.1 support in Avalanche 6

Looks like Windows Phone 8.1 is not supported in the On Premise version of Avalanche 6.0. Windows Phone is supported in the Avalanche on Demand version. 
Hopefully the next release of Avalanche On Premise will support Windows Phone 8

On Premise Version

Avalanche on Demand

Avalanche 6.0 integrated logon

Avalanche 6.0 allows logging into the console with AD credentials. This is disabled by default but can be enabled through the settings. 
Once AD integration is setup users can login to the console as Normal users until an Administrator sets up the permissions. Best practise is to do this through groups within Avalanche and also through AD groups. 

1. Go to Tools - System Settings and Authentication options. Select LDAP and enter the LDAP server. 

Click Save. 

2. Go to Tools - System Users and click on Add user

3. Create a group.

4. Logout of the system and log back in with AD account this time. You will see that the account now appeards as a Normal account.

5. Now logout and log back in as Administrator. Go to Tools - System Users. Edit the group to be which the user account has to be added and add the user to that group.

Avalanche 6.0 Android device information

Click on the inventory tab and then the folder where the Smart device is enrolled. 

Click on the green android symbol will bring up the following useful information

POC 2 - Managing Smart Mobile Device Profiles

Smart mobile device profiles are used to manages settings on android and iOS devices.

1. Select the profiles tab and then select the folder where the profile needs to be applied.

2. Click on New profile and select Apple iOS / Android Devices

3. Provide a name for the Smart Device Profile.

4. If you wish to create a payload at this stage click on the + under Payloads. Select the OS for which the payload is to be created. 

If Android is selected the following payloads are available. 

5. For this example we will select the Passcodes payload. The following is displayed, fill in the requirement and click save. 

6. Reenter the name of the profile here if required and click Save. 

7. The profile as well as payload is now created. Select the required profile and click apply (tick symbol).

The Available profile will now be under applied profile for the profile. 

8. Perform a universal deployment. 

Now lets check what happened to the mobile device whether the payload worked. 

1. Go to the Inventory tab and select the device on which the payload is meant to work. Click on update. 

2. The android device shows synch in progress

3. Once the sync completes the passcode policy is enforced as can be seen below. 

Proof of Concept - Android enrolment in Avalanche 6.0

Smart devices using Android OS 2.3 and versions 4.0+ can be enrolled in Avalanche. I decided to perform a proof of concept in my lab to be able to document the steps required for the enrolment. 
With Avalanche 6.0 smart devices as well as AIDC devices can be managed from the same console. 

To enrol smart devices in Avalanche 6.0 a smart device server needs to be installed. This can be installed on the same server as the Enterprise or Mobile Device server. It can also be installed on a separate server. There can be only one smart device server in an Enterprise. 

Device - Samsung Galaxy S2 on Android 4.1.2

The steps can be broken down into the following:
1. Create Enrolment rules.
2 .Download and Install Enabler for Android. 

1. Create Enrolment Rules

Enrolment rules allow devices to connect to the server and contains - ID, password and the folder where they are to be placed. Each enrolment rule must have a unique ID.

1. Click on the Enrolment tab and select the folder where the rule is to be associated.

2. Under Enrolment rules click on New to create a new rule. 

3. Enter the enrolment ID and password. 

4. Select whether the rule is Group or LDAP. LDAP is only available if Landesk mobility manager is installed. 

5. EULA can be downloaded as template and saved as a text file or a custom file can be selected. I decided to try a custom file called EULA.txt. 

Create a text file with custom text  and save to a location on the Server. At the enrolment rule screen Browse to the EULA file and select. 

6. Click Save.

7. You will notice that the Rule needs deployment. Complete the deployment. 

2. Download and install Enabler for Android. 

There are two types of Enablers for Android:

• GCM - available from Google play store. This enabler can be updated automatically everytime a new Enabler is released. 
• ANS - This is available from the avalanche website. This will not automatically update the enabler. 

For this POC I decided to use the ANS enabler. 

1. On the Android device go to the Wavelink site to download the enabler (or you can have it predownloaded) 

2. Select the appropriate enabler 

3. Select package installer and click Just Once. 

4. If you get the following message, click settings 

5. Under Device Administration select Unknown sources. 

6. Click on Install to install the application

7. Once installed a message is displayed that the application has been installed. 

8. Click on Activate

9. Enter Enrolment ID, password and server. Then click Register

10. Once registered the EULA is displayed. 

11. This completes the enrolment of the device in Avalanche. 

If you check in Avalanche now the device should report.