Managing Devices

This topic covers the various aspects of managing devices in a production deployment.

Checklist: RFID Device Health

Task Reference

Monitor device state

Device States

Monitor device provider state

Device Providers

Check for errors

To debug device errors, analyze the provider log and service logs:

  • %RFIDDATADIR%\Providers\<ProviderName>


The following section provides details on overall log management that could affect the size of the log files mentioned above:

Managing Log Files

Look at event logs to check if there are specific device errors raised from the service.

Check device statistics

Device Statistics

During the operations phase, viewing the device information can provide the usage pattern (whether the connection is open or retrying), as well as provide information about changed properties tracked by device versions. This helps in making sure that the device is in the correct operational state.

Device States

A quick check to validate the health of a device is to look at its current state. The following table describes the various device states.

Device state Description Symbol


An RFID process is connected to the device, or is using the device. The device is online.

If this state is intermittent, and it changes from Open to Closed, a client application might have executed a synchronous Web service call.

Open Device


No RFID process or client is connected to this device. The device is, however, configured for use with BizTalk Server RFID, and may be bound to a process that is not started.

Closed Device


BizTalk Server RFID is trying to connect to the device.

Retrying Connection

Disabled – Failed

BizTalk Server RFID is no longer attempting to connect to the device due to connection failures.

To exit this state, click the device name, and on the Action menu, click Enable.

Retrying Connection

Disabled – Manual

The device has been manually disabled to update firmware, and so on. To manually disable a device, click the device name, and on the Action menu, click Disable. After a device is disabled, it is not available for use until you enable it. Any device in the Open, Closed, or Retrying state can be manually disabled.

Disabled Device

Disabled – Name Conflict

The logical and physical names of the device do not match.

Disabled Device

Disabled – Unconfigured

The device is not yet configured for use by BizTalk Server RFID. This is the initial state of a newly discovered device. To use the device, click the device name, and on the Action menu, click Enable. Set the authentication information such as user name and password.

Disabled Device

Disabled – Maintenance

The device is under maintenance.

Disabled Device

Devices bound to an RFID process that is started should always remain in an Open state. Otherwise, it is normal for devices to be in a Closed state. .NET applications that use the device with the synchronous programming model will open a connection, execute the command, and close the connection. In this case you might see a device state change from Closed to Open and back to Closed.

If you notice a device state that is Open but not part of an RFID process, this could be due to an application that has not closed the connection after executing the command or a cached connection design with the application still running. This makes the device unusable to another application, but the device can still be used from an RFID process.

Retrying. If a device is in a Retrying state, then the BizTalk Server RFID framework is unable to make a connection to the device. Here are some things that you should check:

  • Is the device information (IP address) still valid? Follow the recommendations from the hardware manufacturer. If available, use a serial cable connected to the COM port and check the IP address of the device.

  • Is the device reachable from the network? Can you do a “ping”?

  • Is the device connected from another BizTalk Server RFID instance?

The frequency at which the service attempts to connect to a device is configurable. In RFID Manager, if you right-click the Devices node on the left and select Connection Parameters, you can see a "Connection Retry Interval" parameter. This defaults to one minute, and can be changed to suit your needs.

After a certain number of attempts to establish a connection to a device, the service stops trying and moves the device to a Disabled – Failed state. From the same dialog box mentioned above, you can configure the "Maximum retry attempts" parameter. This defaults to 10 attempts.

In addition, the dialog box contains a parameter called "Connection Check Time."  For connected devices (in the Open state) that are associated with an RFID process, the service has a mechanism to automatically verify the connection periodically. The "Connection Check Time" parameter dictates how frequently the service should verify the validity of such connections. If the device is not found to be alive, the service automatically re-attempts a connection to this device.

Connection checking is done only for devices bound to an RFID process, and is not supported for devices connected only through a .NET client application.

Disabled – Failed. A common reason for this state to occur is that several attempts to connect to the device have failed (by default this is 10). If a device reaches this state, follow the recommendations mentioned in the previous section to debug the problem. Check the provider and service logs for information that shows the problem.

In addition, if the device provider is stopped or recycled while a connection to the device is open, the device state is changed to Disabled – Failed. After the device provider is started, the device state is adjusted appropriately; a connection is attempted if an RFID process is bound to the device or closed if there is no interested application.

In most cases, the device has to be enabled manually before it can be used again. This requires administrator intervention. However, if the device provider raises a discovery event for the same device, then the service automatically enables the device. Enabling a device moves it to the appropriate state depending on RFID applications interested in the device.

Typically, the connection attempts should be successful well within the 10 attempts and are required only for intermittent connection problems with the device. If you notice that devices get to the Disabled – Failed state, temporarily try increasing this value to check if it fixes the problem. Then analyze the reason for the problem by using the provider and service logs.

Disabled – Name Conflict. This indicates that the physical name of a device is different from the name maintained by BizTalk Server RFID (the name with which the device was added and persisted in the RFIDstore database). This can happen in the following scenario:

  • The physical device supports the NAME property and it is a writable property.


  • When starting an RFID process, the service finds that the physical device name is not the same as the internal physical name maintained by the service.

An administrator has to manually enable such a device before it can be used. An easy way to fix this is to rename the device and provide a new name so that the service can apply the same name to the physical name.

This conflict usually happens when a device is added in an offline mode. For example, using RFID Manager, a device is added (a device name is provided) when it is not reachable at the IP address or not connected to the framework. If the device comes online later with a different name than the one provided during the offline device addition process, a name conflict occurs. This problem can also happen if the device name is modified externally by using an IHV-specific tool.

If the device name is modified from RFID Manager when the device connection can be made, this conflict does not occur. Even if the device is in a Closed state, as long as the rename operation succeeds, the physical name and the name maintained by BizTalk Server RFID are in sync.

Device Versions

Device versions are maintained by BizTalk Server RFID in the RFIDstore database to help administrators debug device property changes in the operations phase. The first connection to the device triggers a checkpoint. Note that adding a device does not create a device version by itself. Device property changes lead to a diff, and not to full checkpoints. In addition, the RFID administrator can explicitly store a particular version by taking a checkpoint. This can be done to a particular device that is working well in production before a change is applied, for example updating the device firmware.

To set a device checkpoint
  1. In the console tree, click the Devices node.

  2. In the results pane, right-click a device, and then click Versions.

  3. Select a version that you want to set as a checkpoint, and then click Checkpoint.

To view device versions
  1. In the console tree, click the Devices node.

  2. In the results pane, right-click a device, and then click Versions.

  3. Hold down the CTRL key, select any two versions from the Device Version area, and then click Diff.

    The Diff dialog box displays the properties that have changed.

Device Statistics

Device statistics can be viewed from RFID Manager by right-clicking the device.

The RFID administrator uses the device details to view device connection statistics such as the current device connection state, the processes that are associated with the device, and the reason for connection failure. These details are useful while troubleshooting the connection failure of a device.

To view device details
  1. Click the Devices node.

  2. In the results pane, select the device for which you want to view the device details.

  3. On the Action menu, click Statistics.

    The <devicename> dialog box appears.

    The following table lists the device details.

    Use this To do this

    Connection state

    Displays the current device connection state. This value is the same as the value in the results pane of the Devices node in the console tree. Sample connection state values are Closed and Retrying.

    Consecutive failed connections

    Displays the consecutive number of times the device failed to connect to the BizTalk Server RFID server.

    Interested processes

    Displays the names of all the processes that are connected to the device.

    Last activity time

    Displays the time when the device was last active.

    Last exception on connect

    Displays the error message or the exception that the server issued when it tried to connect to the device.

    Last successful connect

    Displays the time when the device was last successfully connected to the BizTalk Server RFID server.

    Successful connections

    Displays the number of successful connections that the device made with the BizTalk Server RFID server.

    If you see the following conditions, deeper diagnostics are required:

    • If there are consecutive failed connections, analyze the device provider and service logs to debug the problem further.

    • Device inactivity: Look at the “Last activity time” and “Interested processes” values. Check if the Device State is Open.

    • Any exceptions when connecting to the device

Organizing devices into device groups helps the RFID administrator manage the maintenance of the devices. Similar devices or devices in the same location are usually grouped together. This grouping is purely from an administration standpoint and has no impact on how the device events are communicated to an RFID process.

Events from devices are delivered to an RFID process based on the logical device binding.

The main operations that are performed on a device group are:

  • Maintaining a uniform property profile for all the devices in the group

  • Having the same device group password to connect to the device

  • Uniform security settings that enable accounts (domain or local) to perform device-specific administrative operations

A device can exist in only one device group.

You can add, modify, or delete device groups that are listed under the Device Groups node of RFID Manager.

Creating a Device Group

You can add a new device group.

To create a device group
  1. In the console tree, select the Device Groups node or a device group node.

  2. On the Action menu, click New Group.

  3. In the New Group dialog box, type the device group name in the Name field and the device group description in the Description field.

    You cannot create a device group called RootDeviceGroup. "RootDeviceGroup" is a built-in device group that contains all other device groups and devices.

  4. Click OK to create the device group under the selected node.

Moving Devices and Device Groups

You can move a device or device group into another device group by using any of the following methods:

  • From the Device Group option in RFID Manager, drag the device or device group to the new location in the device group node.

  • Use cut-and-paste options.

Using Device Groups

Device groups can be used for applying the uniform device property templates for all the members in a group.

To apply a property template to a device group
  1. In the RFID Manager console tree, click the Device Groups node.

  2. Right-click a selected device group, and then click Apply Template.

    The Apply Properties dialog box is displayed.

    A property template cannot be applied to a device group that does not contain any devices.

  3. Type the name of the template file in the File name box.

  4. Click Load to validate and display the properties in the template.

    If the template is valid, the properties are displayed in the Properties area.

  5. Clear the Select All check box if you do not want to apply all the properties from the template.

  6. Click Start to begin applying properties from the template to the selected devices.

    Any errors or messages are displayed in the Information area. Double-click the name of a device in the Information area to view a list of properties that were not applied.

Properties will be applied to all devices and subgroups within a device group.

Export and import operations can also be done on individual devices. See the following links for more details:

Device Security

In addition to the password that RFID devices expose, BizTalk Server RFID allows a device security authorization model. Any operation that can potentially affect or change the state of the device requires the caller to have administrative privileges on the device.  Having administrative privilege on a device means that at least one of the following should be true:

  • The caller is a member of the built-in administrators group.

  • The caller is a member of the device's custom administrator list. (To view or modify this list by using RFID Manager, right-click a device and then click Security.)

Refer to BizTalk Server RFID: Device Security for more details.

Synchronous Command Model

In addition to being bound to an RFID process, devices can also be used by applications for performing synchronous commands. Such applications must use the DeviceConnection.Open API to open a connection and execute the command. This model allows exclusive access to the device and does not allow another typical synchronous client to use the device.

BizTalk Server RFID allows the device to be part of an RFID process and also available to a synchronous application. We recommend that this configuration not be used to avoid interference in the execution of the GetTags() synchronous command and event processing for the same set of tags in an RFID process.

In addition, there is a DeviceConnection.OpenAdministrationConnection API that must be used only by administrators when the device already has a client connected to perform synchronous commands. Use of this API does not adhere to the single-client restriction.

The account under which the application is running should be part of the RFID_USER group. If the application invokes Web services that change the state of a device or process, then in addition it needs to be part of the device administrator or local machine administrator group. Refer to BizTalk Server RFID: Web Service Calls for details.

There is one device provider instance for each type of RFID device deployed and managed by one BizTalk Server RFID server. As mentioned in the Planning section, it is critical to have the device provider deployment document and the IHV point of contact for the device provider. For a list of vendors, see Hardware Partners (

We recommend that you validate the device provider with the specific RFID device and firmware combination and test it for your scenarios before deploying to production. See Device Providers: Versions and Validation for more details.

The log files for each device provider are located in %RFIDDATADIR%\Providers\<ProviderName> where <ProviderName> is the name used while adding the provider from RFID Manager or RFIDClientConsole. These log files along with the service logs are extremely useful in debugging device-specific problems.

On Windows Server, for better isolation, device providers are hosted as worker processes in IIS.

Here are the provider states that are exposed in BizTalk Server RFID.

Provider state Description

Started – OK

This is the expected state in production.

Started – Unhealthy

This state indicates an error that occurred in the device provider operations. Refer to the provider logs for more details. When RFID Manager obtains the provider status, it looks at all previous faults. A provider fault could be due to an orphaned thread when checking a device connection. So if there is one particular device that is not responding and causing provider faults, the provider state could be changed to unhealthy. Analyze the provider log to check if a particular device has caused the problem. Contact the IHV and Microsoft point of contact with the log files.


This state indicates that the device provider is stopped and there will be no interaction with the specific set of RFID devices that it manages.

This could be due to:

  • Device provider is explicitly stopped by the administrator or not yet started after registering.

  • A problem that occurred during runtime that stopped the provider.

If you notice that the provider is in the registered state in production, save the provider and service log files for debugging the issue. Then try starting the provider from RFID Manager. Refer to Hosted Provider / RFID Process Failures if the provider does not start. If this does not resolve the issue, contact the IHV point of contact and the Microsoft point of contact for the next set of steps.

Mobile devices can be remotely managed from RFID Manager. It is important to understand that the intermittent connectivity of these devices can lead to repeated connection attempts. In cases when these devices are part of an RFID process, it is possible that the device state changes to Retrying or eventually to Disabled Failed.

Firmware upgrade in the devices should be completely tested in a staging environment before deploying to production. The device provider used must have been tested by the IHV using the PCT (Provider Certification Test suite).

BizTalk Server RFID exposes a firmware upgrade API but requires the device provider to support successful completion. So in most cases, this operation is done by using IHV-specific tools.