Yes. When a product is installed with product access management configured, a permit is always required, and the administrator controls access to permits.
The old software license management and new product access management are not compatible with each other. To take advantage of product access management, customers must uninstall any existing licensing mechanism before installation. Any SLM permits become redundant and product access management permits must be requested.
No. IBM provides a permit file that is structured according to your needs as defined in the request form. You are not able to configure the permit file after it is delivered. If the structure changes over time, come back to IBM and request a replacement permit file.
No, product access management is based on third-party technology from SafeNet inc.
No, you can only run 1 Sentinel RMS license server per machine. You should be able to use permits from multiple software vendors on the same server (the only aspect to be watch out for is the version of the server software).
Yes. You can maintain permits on multiple servers. A basic scenario would be to use two servers on your network to ensure that some permits are always available. You might have half of the total number of permits on each server. Under default operation, the client broadcasts a request to all servers on the network, and uses the first one to respond. It is possible to configure the client to go to a specific server, and also to configure a search order. In this situation, configure half your clients to connect to server 1 first, and half to connect to server 2 first. This configuration balances your usage over the two servers and also gives a level of backup in the event of server failure.
Depending on deployment, the following apply:
Normal connected-to-the-server use : The entitled number of permits are stored on a server at the customer premises. When a user starts a product with access management enabled, a permit is requested from the server. Based on availability, either a permit is provided or the request is rejected (because a permit is not available). When the user closes the product, the permit is returned to the server.
Borrowing from a server : While there is a network connection from the client computer to the server, it is also possible to borrow a permit. Permits can be borrowed for a minimum of a day and for any period up to five years. While borrowed, the permit is stored on the local computer, and is only available for use on that computer.
The local permit is used instead of attempting to gain a permit from the server. This me that the computer can disconnect from the network and still use the protected product. While the permit is borrowed, it is not available for use from the pool of permits on the server. This borrowed permit is usable until the day count reaches zero. When the day count reaches zero, the permit is not usable on the computer that borrowed it. The permit is made available on the server again.
Borrowing remotely : If there is no network connection, it is possible to use tools on the product distribution media to borrow a permit remotely. When borrowed, the experience is the same as for borrowing from a network. Note that for this process to work, there must be a method for exchanging text files (for example, by email or USB stick).
Like the rest of our products that use Microsoft Installer, silent installs across a network are possible. The parameters that are used are described in the IBM i2 Product Access Management Administration Guide.
There is no specific way to "pull" a permit back to the server. Where 'connected-to-the-server' use applies, the permit is returned as soon as the program is closed. In the 'borrowing' scenario, the recommendation is to implement sensible borrowing times.
For example:if the user is working remotely for 10 days, then set the borrowing time for 10 days. If the computer is stolen after seven days, on the 10th day the permit would be automatically returned. Alternatively, you can request a replacement permit file from IBM, which would then supersede your original permit file.
Yes. Remote borrowing is possible, and borrowed licenses can be trferred on a USB flash drive.
Each traction that is carried out by the server is logged in the following format:
0 1 MTY1NQ== Fri Mar 12 14:42:55 2010 1268404975 ANB.main v8 0 1 0 Administrator TestBed_Shwcase 8.3.0.900 1 - - - - - - 0 - - - MA== 655259 MTI2OTA2MDIzNA==This log file can be exported as a CSV file. By looking at the highlighted entry, you can see how many permits are in use at that moment. See the IBM i2 Product Access Management Administration Guide for more information.
The Sentinel RMS license server must exist in the same subnet as the client broadcasting.
The approximate process for borrowing remotely is as follows:
On the remote computer:
On the network that is connected to the permit server:
On the remote computer:
No. 8.9 products are not compatible with earlier versions.
Sentinel RMS license server includes support for the following operating systems:
Yes. Through some implementation setup, permits can be limited. In your design,
identify at least two servers:
If a user wants access to a product, and there are no permits available from the first server, provide access to the second server and use those permits.
The virtual environments that are supported for each of the products that use access management are listed in the relevant system requirements documents.
It depends on the deployment:
Normal connected-to-the-server use : When a user starts the product, the computer requests a permit from the server. While the permit is allocated, that permit cannot be used by anyone else until it is returned to the pool. When the user closes the product, the permit is made available for use on another computer again.
Borrowing from a server & Borrowing remotely: In the 'borrowing' scenario, a permit is allocated to the computer for a time period, ranging from one day up to five years. The advice is always to set a sensible 'borrowing' period. For example, if the user is working remotely for seven days, set the period for seven days.
Permits can be borrowed for a minimum of one day.
The lock codes that are used to identify each server are generated using the server's MAC address and disk ID. The information is encrypted with an SHA-256 algorithm. It is not possible to work back to the original information that generated the code.