The State of Washington public higher education institutions currently participate in the Esri Site Licensing program. This paper describes the main challenges involved in managing the site license and how we have dealt with these challenges. Although the site license includes all of the public universities and community colleges in the state of Washington, this paper focuses on University of Washington's methods of administering the site license.
The main issues in administering the site license are:
- Software distribution/installation
- Software licensing (client/server)
- Technical contacts and software support
- License file (keycode) generation
- Virtual campus subscription
Each of these issues is discussed, including particular problems we have encountered, as well as some methods of automation we have used to solve these problems to create an efficient and successful site license for the University of Washington.
The University of Washington (UW) pioneered Esri site licensing for the State of Washington in the mid 1990s. Several units within the University had a stake in maintaining the site license. The College of Architecture/Urban Planning, the College of Forest Resources, the department of Geography, the department of Geological Sciences, and the College of Ocean and Fisheries Sciences were the key players, with scattered single-seat Esri software installations at other places on campus.
Originally, the site license was administered in a loose, disorganized fashion. Essentially, one department (Geography) would pay the annual license fee, and then each "seat" would repay a certain amount to Geography. In order for Geography to recover the license fee (about US$17,000 annually), users were charged at a rate of US$100 per ArcInfo seat and US$50 per ArcView seat. Once the site license fee was repaid, seats were "given away" for no fee.
The situation was far from ideal. Those who needed the software the most were the first to pay, while those who had the least need were the last to pay, or if they were lucky, they would get by without paying at all. Another problem with this method was that the departments with the largest installation base were essentially subsidizing departments with smaller installation bases. Apart from the inevitable inequities in payment of the licensing fee, the logistics of actually recovering the fee were nightmarish at best. A single purchase order was created to pay the licensing fee, and that single purchase order sometimes had an excess of 50 single budget numbers and PI signatures.
Later, a more efficient method was settled upon for recovering the licensing fee. Geography still fronted the licensing fee, frequently on a budget that would never be able to cover the actual fee. Key players in the installation base met and agreed upon percentages to be paid by each department. Assuming the departments paid their respective portion of the fee, they could install software on as many seats as they wanted. "Delegates" were selected to work within the respective departments for recovering the fee for Geography.
Eventually, other public higher education institutions within the state became more interested in a site license solution. State universities other than the University of Washington had large enough installation bases to warrant getting a piece of the site license. A few community colleges were also actively involved in teaching GIS practice and theory. Finally, Western Washington University started negotiations with Esri for a statewide public higher education site license. As luck would have it, the University of Washington's administration simultaneously came to the realization that universal access to GIS software for students, staff, and faculty was important enough to fund centrally. This meant the end to the "nickel and dime" methods of recapturing the licensing fee. This summer, we are approaching the end of the first year of the statewide public higher education site license contract.
Administering the site license requires being responsive to users on a number of different fronts. Over the last few years we have developed methods to streamline the ways we deal with user support, which has led to better customer support and less work on the part of the license administrators.
The rest of the paper will discuss the foremost issues in the site license. Each of these issues will be discussed in turn, including particular problems we have encountered, as well as methods we have used to solve these problems and create an efficient and successful site license for the University of Washington.
Nearly all major issues fall into one of these 5 categories:
- Software distribution/installation
- Software licensing (client/server)
- Technical contacts and software support
- License file generation
- Virtual campus subscription
Our main way of formulating methods and policies for each of these issues is through discussion at ad-hoc meetings of the University of Washington Consortium for Geographic Information Science (UWCGIS), or through e-mail correspondence among the core group of the UWCGIS members.
Software distribution is one of the largest parts of administering the site license. Apart from basic logistics, we have to consider issues of legality and ethical propriety. The site license allows included Esri software to be installed on all computers owned by public higher education institutions of Washington state. However, a few stipulations exist, most notably, that software cannot be used either to generate profit or for projects that directly compete with for-profit companies. Both ArcView 3.2 and 8.1 for Windows are unkeyed software, which can be installed on any machine without central licensing service, so we attempt to keep tight control on how the media for these 2 applications are distributed.
Points of Contact for software distribution
The main method of software distribution is through main points of contact in units strongly involved in GIS education and research. A staff person in each unit is identified as being the "point of contact" for software distribution within that unit. Typically this staff person works in the capacity of network or system administrator, instructor, or other GIS support staff. When users request software installation, the contact person either personally installs the software or distributes a backup copy of the installation media to the user. After the software is installed, the media is returned to the contact person. This way, we are able to exercise some control over how unkeyed media are distributed.
Some users work in units that do not have a designated contact person. Some of these units are either small, understaffed, or are only marginally applying GIS methods. For users in these units, the UW Map Library maintains backup copies of Esri software installation media on short-term reserve for check-out. This is an obvious hole for software piracy. One possible "solution" we are considering is restricting lending of unkeyed software to staff and faculty (though this assumes that staff and faculty are more honest than students!). Frequently research faculty will employ research assistants for performing software installations anyway, this the point of attempting any complete control over piracy may be moot.
The main point is that we attempt at every turn to limit the opportunities for software piracy.
Serving software installation media
For ArcInfo software, we have employed a method of serving software installation media for the majority of users.
A staff person in Geological Sciences creates Solaris versions of ArcView 3.2 and ArcInfo 8.1 "software images" on a Sun Sparc machine. The installed software directory is archived in a zip file and placed on a web site accessible only by UW IP clients. Due to the directory structure of ArcGIS software on UNIX machines, it is possible to create an archive of the entire installation directory. When the installation file is unarchived, the user needs only to set a few environment variables (e.g.., ARCHOME, AVHOME, PATH, LM_LICENSE_FILE, LD_LIBRARY_PATH), and the software will run.
Most of the UNIX ArcGIS users on campus use Sun machines, so this method has worked well for distributing installations. No action is required on the part of the server; the only action required of the client (user) is to download and unarchive the installation file. Using IP-restriction on the distribution site allows us to prevent non-UW clients from downloading the software.
The Windows version of the installation architecture is quite different from the UNIX version. Because the Windows version installation requires registry editing, it is impossible to create a single "software image" for distribution. Instead, the original installation files are copied from the CD onto a samba share on a UNIX server. Clients (users) can map the samba share as a network drive and run the setup.exe files for the desired software. The only software served by this method is ArcInfo, which needs a license server to run. An additional security measure we use is to restrict the samba share (using the hosts allow parameter for the share) to IP clients within the washington.edu domain.
Extensive, step-by-step web-based instructions have been created in order to guide users through the installation process. While a considerable amount of effort has been spent developing these instructions, the benefit to users and administrators is clear. Users do not need to ask questions, and administrators do not need to spend time answering the same questions time and again.
Software licensing (client/server)
Once client users have the software installed, they need access to the ArcGIS license. We keep 3 UNIX machines (Sun SparcStations) with a large number of licenses (999) available for UW connections. As long as clients are attached to the network, they can use ArcGIS licenses from these servers.
The servers are housed in different buildings, so if one building experiences a network or power failure, the other servers will still be available. Clients can specify multiple license servers by using environment variables.
Under UNIX the environment variable pointing to multiple servers can be set by the following command, assuming license servers are called host1, host2, and host3:
setenv LM_LICENSE_FILE 27005@host1:27005@host2:27005@host3
#Bourne or bash syntax
(Note: the hosts specified must be defined in /etc/hosts).
Under windows, users can set an environment variable (inside System/Environment properties within the Control Panel):
variable name variable value
(Note: the hosts specified must have their domain extensions registered in DNS within TCP/IP properties within the Network properties in the Control Panel).
Instructions for setting up these environment variables are also give in the installation instructions mentioned before.
In order to run ArcGIS, the client must have both the software installed an a license manager either running or available. In the unlikely event that someone obtains a pirate copy of ArcGIS, that client would still need access to a license server. In order to restrict unauthorized access to our license servers, we use FLEXlm's license.opt file to limit license clients to the UW domain's IP ranges. Here is the contents of our current license.opt file:
INCLUDEALL INTERNET 128.95.*
INCLUDEALL INTERNET 140.142.*
INCLUDEALL INTERNET 128.208.*
Any clients outside these IP ranges will be unable to request an ArcGIS license.
Technical contacts and software support
Our installation base at the UW is large and continuously growing. Supporting this large number of user requires a concerted effort to respond to technical incidents and to provide complete and speedy responses to user problems. We have a multi-headed approach for dealing with user problems, so that responses are best fit to the type of incident.
Our site license gives the UW 4 designated technical contacts. Technical support requests sent to Esri must originate from one of these 4 persons. The statewide license provides additional technical support contacts for the other institutions around the state.
Technical support issues get the highest priority attention in terms of software support. We define technical support issues specifically as "software problems." For example:
- the Select by theme functionality in ArcInfo 8.0.2 does not result in consistent selections when ArcInfo coverages are the theme data sources.
- installing ArcInfo 8.0.2 made my machine crash.
- the ArcView 3.2 request Line.ReturnStart does not always return the first vertex for the line (depending on the spatial orientation with respect to the compass, it sometimes returns the last vertex).
We have had some turnover in the technical support contacts, so rather than giving users the list of technical support contacts, we maintain an e-mail alias which acts as a distribution list. Users requiring assistance are directed to send e-mail to the single address for Esri technical support; the message is forwarded to the technical support group, and whoever acts first on the issue responds to the user as well as to the other technical support contacts.
A web page instructs users to supply pertinent information that is necessary for logging a technical support request with Esri (e.g., client name, software, version, hardware specs, particular error message, description). Future plans include the creation of a CGI-based application that will force users to include all pertinent information before making a technical support request.
A web-accessible database is maintained which contains all Esri technical support correspondence, so that users around the University can review "solved" incidents before requesting new help.
Currently the UW has a number of different courses in which GIS is used to some degree. Many of these courses are concerned with teaching GIS theory or practice, while others are specific science courses that rely on GIS as a tool. Courses that use GIS at the UW can be browsed at the UWCGIS web site.
From the standpoint of site administration, we place the burden of training users in software applications on the respective units that either teach or use GIS. The exception to this is covered under the next topic, "General GIS Help."
General GIS help
We have several avenues for students, staff, and faculty to get general assistance with GIS issues.
- UW GIS E-mail listserv
For all types of general GIS support, we have a local UW e-mail based listserv. Anyone, either from within or outside of the UW can subscribe or post messages to the list. This list is not meant to take the place of larger worldwide list, such as ArcView-L or Esri-L, but allows local users to communicate with each other. The UW GIS listserv is the primary method for GIS users at the UW to keep in contact. The list is kept open and unmoderated, mostly for the sake of keeping channels of communication as open as possible, but also to minimize any work the list administrator needs in order to keep the list running.
In addition to acting as a help line, the listserv is used to make announcements regarding new software, job opportunities, technical tips, conferences, or any GIS-related news. Real-time archives of the list are kept on-line with the use of hypermail, an e-mail-to-web list freeware for UNIX. The listserv is run on on the UW's uniform access machines with listproc software.
- Specialized help
Map Library GIS Support
The UW's Map Collection/Cartographic Information Services Library employs a full-time librarian dedicated to GIS support. Users both inside and outside the UW can send requests for help to a special e-mail address for GIS help from the library. Generally these requests are for help locating particular data sets or for requests to obtain installation media. The Map Collections Library also maintains a small drop-in lab which has several computers loaded with ArcGIS software. This lab is open for access by users from both inside and outside the UW.
For all other GIS help requests that "fall through the cracks," we have established an e-mail help line to entertain any type of request for assistance with GIS issues. The e-mail line is monitored by a student TA or RA during the regular school year, and by one of the technical support contacts during summer term. The purpose of the GISHELP line is not necessarily to provide direct assistance to users, but more often consists of directing the user to a local "expert" in the particular area of need, whether the need is as simple as finding data or as complicated as dealing with multivariate raster layer analysis.
The GISHELP line uses a complicated procmail recipe for keeping track of incident numbers and forwarding the incoming message to the GIS helper. You may download the procmail recipe and use it without restriction. Like our other e-mail lists, correspondence to and from the GIS helper is also continuously archived with hypermail, so that incidents can be reviewed by new helpers or by users before they send new requests.
License file (keycode) generation
While most users at the UW rely on the 3 common license servers to obtain user-level ArcGIS licenses, many users need to or prefer to run their own license server. Especially for users that are running hosts that are not connected to the UW network with a UW domain IP, or users that are not connected to any network (e.g., laptops in use during field work), running a local license service is the only way to run ArcGIS. For those users who need to run their own license server, we only require that they provide computer location and IP address. PC users also need to purchase their own sentinel key, though we keep a number of "spares" around for temporary lending.
In the "bad old days" we were allowed to submit a single request for keycodes in each year, regardless of the number of license servers. Additional requests for keycodes could be submitted, at additional cost.
We considered it a huge advance to be able to create unlimited keycode requests on line using the myEsri web site. Not only did this save money, it also allowed us to generate keycodes any time, without waiting for our Esri contact to have the keycodes created. In addition, if a keycode is generated with erroneous server information (such as hostid or sentinel key number), a new keycode can be generated quickly and easily. I'm sure the Esri contacts were also glad not to be burdened with generating keycodes.
We have developed a Perl-CGI based tool that allows users to manage license requests on-line with minimal action from the site license administrator.
A few pages exist to familiarize users with the functionality of the system.
The Create your Profile choice on the index page opens a form allowing users to create a user identity (with a password).
The user profile is entered and stored as an HTML form.
Because the user profile is stored as a form, users may change personal information at any time by using the web form, by selecting the Update your Profile choice on the index page.
When the user profile is created, e-mail is automatically sent to the site license administrator notifying of the presence of a new user on the system.
After the user identity is created, the user can select from the other actions on the index page (updating user profile, requesting license, or reviewing/updating license requests). In order to perform any of these actions, the username/password must be entered to gain access to the other functions.
The user may create new requests for licenses on a host-by-host basis.
The form includes some error checking to make sure all fields are entered. Host profiles are also stored as a forms, so updates can be made at any time by selecting the Review/Update License Requests choice on the index form.
When the host profile is created or modified, e-mail is automatically sent to the UW site license administrator, as well as to the State higher education site license technical administrator. The e-mail message contains all pertinent information for creating the keycode. This way, the administrator receives mail notification when someone needs a license, and all necessary license information is provided.
With this new information, the license administrator can visit the myEsri.com site, create a new keycode, and have the new keycode sent directly to the user. In the best circumstances (assuming the user has already created a profile), the turnaround time between a new user request and that user getting the new keycode is less than 10 minutes.
You may download the source code for the CGI and use it without restriction.
Virtual campus subscription
The site license entitles us to a certain number of complimentary courses on the Esri Virtual Campus (VC). We have developed a similar application for managing VC enrollments.
The main page is similar to the main page for the keycode request system, except that it also shows courses that are available through the VC site license subscription.
The index page is generated by a script rather than from static HTML so that it can read the number of enrollments and generate a report on a campus-by-campus basis. The list of classes is also set only once in the source script, so that subsequent forms read from the same list of classes.
By selecting the Create your Profile choice, users can create profiles with a user-id and password
The user profile is also created and stored in a web form that can be updated later.
When a user creates a profile, an e-mail message is sent automatically to the site VC administrator.
After the user profile is created, users may request new course enrollments by selecting Sign up for classes on the index page.
The user receives a confirmation after the request is submitted.
Simultaneously, an e-mail message is sent to the site VC administrator. The message contains all necessary information (i.e., the user's e-mail address and name of the course).
The site VC administrator can then enroll the user in the desired course
By selecting the List classes... option on the index page, users can review the courses they have requested.
You may download the source code for the CGI and use it without restriction.
Managing a university site license is no simple matter. Keeping up with requests for resources, providing help for users, maintaining a good flow of information all require time and work on the part of the license administrators. Frequently these administrators do not get any extra benefit from these activities, but the benefits they provide are immense. These are the unsung heroes of the University site license program.
The tools we have created do not add anything to the site license within the University of Washington, but they make the job of administering the license very much easier. The tools have taken quite some time to develop, and are by no means efficient or elegant, but they get the job done!
If you download and use the tools, then cheers and send me a six pack of authentic Czech Pilsener if you feel generous.