How to add an asset name in MSP3.2 ?

Hi,
I am looking for an 'how to' documentation to add an asset name to a mobile device in MSP Control edition. I did not find a clear explanation into the user guide.

thanks for your help
Allan Herrod
If the section on the

If the section on the UserAtttibutes Control Module on page 76 in Chapter 5 of the MSP 3.2 User Guide does not contain the information you need, then please explain in more details what you are trying to accomplish.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jamie Glover
I also have the same question

I also have the same question, I looked at the user guide and at the section you suggested but it is not very clear to me. I have asked people in support but no one seems to know. Are there any steps that you can walk us through to get this working? Also - do you need to have the control edition to get Asset names working, or can you at least get a limited version working with a provisioning licence?
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
I would love to give you step


I would love to give you step-by-step instructions for this, but your requirement is still too vague for me to do that.  I need to know more than that you want to assign an asset name to devices.  I need to know whether you want to do that on the device or on the server.  Perhaps it will help to provide a little background so you can understand the capabilities and then tell me what you want to do.  Then I can tell you exactly how to go about it.

First, MSP 3.2 Asset Management functions are ALL available in Provision or Control Edition.

Second, MSP 3.2 has no "built-in" concept of or management based specifically on Asset Name.  However, MSP 3.2 supports custom device attributes that can easily be used to deal with Asset Names or any other piece of information you want to assign track about a device.  Because of the especial interest in Asset Names, MSP 3.2 pre-defines a custom user attribute called "userAttribute.assetName" just for convenience.  But you can create and use your own custom device attribute if you prefer.

Third, MSP 3.2 treats all device attributes the same, allowing you to device to search by them, display them in lists and detail pages, and use them in rules.

Fourth, custom device attributes can be entered in 3 basic ways:

1. Entered on server by importing a CSV file that matches a known device attribute and value (e.g. UUID or serial number) to determine the deivce to a assign new device attribute value, such as Asset Name.  This can be good for mass assignment of Asset Names.

2. Entered on device by device user using the UserAttributes Control module, either via keyboard or barcode scanner, then sent back up to MSP.  This can be good for entry of Asset Names when devices are being deployed.

3. Sent from MSP to device then sent back to MSP.  This is not so good for Asset Names since it is usually too much work to send a unique value to each device.

If you can look at the above and give me some idea of what you want to do, I can tell you how to do it.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jamie Glover
I just wanted to follow this

I just wanted to follow this post up, I got in touch with Allan Herrod and he explained to me how this can work and today I have been on a customer site and successfully demonstrated importing asset names into MSP 3.2, here are the details:

I can create a csv file which will update the asset name as your customer requires.


Here is an example:
identity.serial,6356520800300,userattribute.assetname,HHT1
identity.serial,6356520800301,userattribute.assetname,HHT2
identity.serial,6356520800302,userattribute.assetname,HHT3


Assuming the above 3 serial numbers were valid serial numbers and existed in your MSP system you could import this list and your 3 devices would be called HHT1, HHT2 & HHT3 respectively.


The general guidelines for the CSV file are as follows:
Each row can have exactly and only 4 columns.
The first column is the attribute to match; the second column is value to match to that attribute.
The third column is the attribute to set when a match is found; the fourth column is value to set that attribute to.
You can use any two attributes you want but be aware that if more than one match is found, it may set values for more than one device per row.
The CSV file itself is imported in the Library >> Attributes page from MSP.


Also be aware that this relies on the serial number appearing in MSP which on some devices may not be supported, but it in my case today it did work on the MC70 which is was very helpful..! 

Make sure you edit the preferences tab in MSP to make the serial number and asset name columns visible too!

Thanks Allan for your help yesterday!

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Michael Holman
I have a customer that loves

I have a customer that loves the fact that we can "Ask the User" to enter an Asset Name.

Issue is it asks after Cold Boot on CE5 devices.

Can this entry be made persistent once entered by the user?
I pitched it as "you want this in case your device moves to another location" but they want persistance without having to maintain CSV file.

Any feedback is appreciated.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
All Device Attributes are

All Device Attributes are stored in the device registry, and ones entered by the device user via the UserAttributes Control Module are no exception.  As such, they are cleared on a cold boot on devices that are not running WM5 or higher.  The Control.UserAttributes Settings Object is persistent, so when it detects that the entered value is gone from the Registry it requests it to be re-entered (if you chose to have it keep checking).  That is why it is bahving as you see.

You can certainly create a .REG file to persist the value assigned to any Device Attribute across a clean boot.  This is not currently a feature of the UserAttributes Control Module and it is questionable whether it should be.  The issue with making such a thing persistent via a .REG file is that .REG files can interact with each other and represent a parallel method for persistence that could conflict with later uses of the UserAttributes Control Module.

Having a future enhancement to the UserAttributes Control Module that provides a means to make the value entered persistent across future cold boots does sound like a valuable thing to do, but it would require some investigation to see how it might be done.  And like any enhancement, it would have to wait for resources to become available and would have to be traded off against a very long list of desired enhancements waiting to be done.  If this is very important to this customer, then please file a GRIP with details about the opportunity.

In the mean time, if you want a work around, you can arrange to save the registry value in a .REG file.  You could do this with custom code, either deployed in a small application or added to a custom application.  Simply preserve the value of the following registry key via a .REG file stored in ]\Application:

  [HKEY_LOCAL_MACHINE\Software\MSP\Attributes]
  "assetname"="assetnamevalue"

Just be sure to understand that doing so will have implications on the ability to use MSP to later change that value since each time the device is cold booted it will revert back to the value in the .REG file.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Damian Stock
Allan, I have a similar

Allan,

I have a similar issue with a partner who wants to set the device name via MSP. Obviously we can ask the user or staging person to enter the device name, either manually or via a barcode, however it would be ideal if this value was then cold boot persistent.

Maybe we need some type of prebuilt packages to send to the device to write these types of entered values into registry files for re-applying in the event of a cold boot. Would it be possible to produce a list of such values and the MSP and system registry entries for them?

Thanks,

Damian

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Damian Stock
Allan, I have a similar

Allan,

I have a similar issue with a partner who wants to set the device name via MSP. Obviously we can ask the user or staging person to enter the device name, either manually or via a barcode, however it would be ideal if this value was then cold boot persistent.

Maybe we need some type of prebuilt packages to send to the device to write these types of entered values into registry files for re-applying in the event of a cold boot. Would it be possible to produce a list of such values and the MSP and system registry entries for them?

Thanks,

Damian

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Damian Stock
Allan, I have a similar

Allan,

I have a similar issue with a partner who wants to set the device name via MSP. Obviously we can ask the user or staging person to enter the device name, either manually or via a barcode, however it would be ideal if this value was then cold boot persistent.

Maybe we need some type of prebuilt packages to send to the device to write these types of entered values into registry files for re-applying in the event of a cold boot. Would it be possible to produce a list of such values and the MSP and system registry entries for them?

Thanks,

Damian

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
Damian; I agree that having


Damian;

I agree that having a way to persist one or more device attributes across a cold/clean reboot is a valuable feature that we should look into providing in the future.  The real trick in any such solution is how to make sure that the value persists only as long as it should persist.  If a new value is assigned to a device attribute or if the value of a device attribute is deleted intentionally, the persistence needs to match.  So, we would don't want to rush into a general solution that does not solve the whole problem.

For now, the workaround would have to be to manually persist any device attributes you want to be cold/clean boot persistent by writing them to one or more .REG files placed into \Application.  For an attribute like assetname that probably gets set once and should seldom be changed, this may be fairly easy to do.  In the general case, it would be more complicated.

I am not quite sure what you meant when you said "Would it be possible to produce a list of such values and the MSP and system registry entries for them?".  Do you mean you want us to provide a list of all possible device attributes and where they can be found in the registry?  That does not really make sense because device attributes are user extensible and you can add as many as you want and name them what you want.  In fact, while the assetname device attribute is pre-defined for convenience, there is nothing built-into MSP that relies on that specific attribute and you could use any attribute you want to name devices and have comparable functionality.

The MSP Console UI will show all the device attributes currently defined to have values for each device.  As far as where a device attribute is located in the registry, that is formulaic and easily described.  Device attributes that are extenisble must all be in the userattribute sub-group.  The values of all device attributes in the userattribute sub-group are stored in the registry under the key:
HKEY_LOCAL_MACHINE\Software\MSP\Attributes.

If a device attribute name has no additional sub-hierarchy (e.g. userattribute.siteID or userattribute.assetname), then the value will be found under the above key, for example:

[HKEY_LOCAL_MACHINE\Software\MSP\Attributes]
"siteID"="value"
"assetname"=value"

If a device attribute name has one or more additional levels of sub-hierarchy (e.g. userattribute.mygroup.myattr or userattribute.mylevel1.mylevel2,myattr), then the value will be found under the above key with additional sub-keys for each additional level, for example:

[HKEY_LOCAL_MACHINE\Software\MSP\Attributes\mygroup]
"myattr"="value"

[HKEY_LOCAL_MACHINE\Software\MSP\Attributes\mylevel1\mylevel2]
"myattr"="value"

Allan
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jamie Glover
Once you have imported your

Once you have imported your CSV file into MSP what is the best way of managing the list of asset names? For example can you import an updated CSV file in the future and if so will that just overwrite the previous asset names or will it append to the current list?

Also if you wish to delete devices (because they have gone for repair) can you do this with a CSV file or do you need to manually delete them from the web page?

Many thanks.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Andrew Knight
You must manually delete

You must manually delete devices from the MSP console UI to remove them from the system.
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Allan Herrod
Importing a CSV file with

Importing a CSV file with updated asset names will override any asset names currently assigned to the matching devices.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Edward Michalsen
Hi, One of our partners has

Hi,

One of our partners has an issue bulk importing the assetname. Or I should say that on two identical installations of MSP 3.2 with SQL express show different behavior when importing from an CSV file. The partner can import based on serial on his test server (or his laptop that is) but at the partner he cannot import using serial number such as this; “identity.serial, ,userattribute.assetname,Term1”, but the same server can import when he is using the UUID. One variable that diffrenciate the two environments is the terminal type. Partner test site use serials from MC70’s and the customer serial numbers comes from their MC9000’s.

So, can anyone help me brainstorm why this is happening?

Edward
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jamie Glover
This is just a thought... but

This is just a thought... but I beleive that some devices or some OS revisions may not support the serial number attribute in MSP 3.2.

I don't know what version of MC9000 you have, but maybe it does not support the serial number attribute?
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Allan Herrod
Havd they verified that the

Havd they verified that the devices for which this is not working are in fact reporting serial numbers?
When a CSV is imported, it cannot assign asset names by serial number unless MSP knows the serial numbers for the devices.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Edward Michalsen
Thanks Jamie & Allan Jamie,

Thanks Jamie & Allan


Jamie, this is not an attribute thats pushed to the device (yet), rather imported into MSP DB.
Allan, the devices has been staged, and the serial number has been verified to exist in MSP.


Edward

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
Can you send an example of

Can you send an example of your CSV file?
Also, be sure you are uploading the CSV file from the Library->Attributes page NOT from the Transfer->Import from CSV page.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Edward Michalsen
Hi Allan, got the cvs file

Hi Allan, got the cvs file from the partner today.


The partner uploads the attached cvs file via "library -> attributes". Keep in mind that he is able to fuse it with his test server, which is an identical installation as on the server (local SQL express).

Thanks for your help.


Edward.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
Well, I see nothing wrong

Well, I see nothing wrong with your CSV file.
So, are you saying that both MSP servers have all the devices with those serial numbers shown but that importing the CSV into one assigns the asset names to the devices and importing it into the other does not?
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Edward Michalsen
Allan, that is correct. I

Allan, that is correct. I have asked the partner to verify this.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Edward Michalsen
Hi Allan, So I've verified

Hi Allan,

So I've verified with the partner, and this is the setup. He also mentioned that both bave been upgraded from 3.1->3.1.1->3.2

Serial numbers are in both cases in the MSP through staging.

If they are running on a test license, and have exceeded their device count - will that result in behavior like this?


























Test environment


Production environment


Windows 2003 R2 on VMware


Windows 2003 R2 on VMware


MSP 3.2 controller edition


MSP 3.2 controller edition


SQL 2005 express


SQL 2005 express


MC7094


MC9094-S


Importing csv file via Library->Attributes


Importing csv file via Library->Attributes


Import successfully


Import fails


Edward

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
No, licensing (specifically


No, licensing (specifically the exceeding of available licenses) could not produce this effect.  So long as at least 1 control license is installed, all MSP Control Edition functionality will be available for all devices.  The only thing that exceeded the installed licenses will due is produce a warning.

When you say that the Import Fails, what is the symptom?  Does it generate an error or does it just not assign the asset names?  Is there anything in the event log after the "failure"?

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Log in to post comments