A Perfect Storm : Domain Change Made Harder Than It Has to Be

So in my last post, I noted that we upgraded to Sierra 2.4. Among other things, this is supposed to give us the _replace function for a wildcard, to reduce the security warnings users get when trying to go through the WAM to the databases.

Now, winter commencement was Dec. 15, 2016 (Thursday) but we had word that some instructors were allowing students to keep working until the 20th (Tuesday), so we asked for a delay to the upgrade to the 21st. That left the 22nd to check it out before we closed on the 23rd for the holiday break. Time zones were a little odd – it seems the Australia office was handling it. It went well.

Back to work on Jan. 3, 2017. Supportal didn’t like my login. Had to have that reset. Finally got in on Jan. 4 (Wednesday) and asked for the domain change. Got an email back from III: “I came to know from my support colleagues that you will be changing your domain and want to install the new SSL certificate immediate after that. Once your domain got changed and you are ready with the SSL, please raise the service commitment by visiting the URL and we will take care.”

Sounds good.

Friday 6th we were closed for snow, but I had a call in for our I.T. people already for the certificate. The catch apparently was, they were already tied up doing their own certificate updates just before the snow day. So they got back to me to generate a certificate on the 9th (Monday), and I tried to send that on the 10th. Supportal would not allow me to attach the certificate (which you would think would be allowed, but apparently was not). So, attached to the reply to the email. Later, converted to text and entered as comment in the Supportal.

I’m still getting no response on the domain change from III. No email either. I keep asking.

We have a holiday on Jan. 16 (Monday) and classes begin on the 17th. Got back and still no notice from III. I update Supportal and send email to the certificate person. Email auto-reply says he is out until the 19th.

The nice thing about banging your head against a brick wall is how much better it feels when you stop. I used the Supportal and email to postpone the domain change until spring break in March. Because if there is something we do not want to do, it’s try to change domains while classes are going on.<cue: foreboding music>

Finally got a response to contact them at the beginning of March to remind them. Will do.

March 8 Wednesday

And I thought I had a bad time in January

So, I had an email from the person on this back in January, to remind him at the start of March that we wanted to try this again March 20, the Monday of spring break week. That would leave us Tuesday, Wednesday and Thursday (we’re closed Friday) to make our changes at this end.

Provided it happens, of course.

I put it in the Supportal at the end of February. Thursday March 3rd I emailed. Monday the 6th I phoned (and had to leave voice mail for anyone who could help – this is a Service Desk?!?). Today I tried Supportal and called again, and at least confirmed he (let’s call him K) still works at III, but couldn’t answer the phone at the moment, and neither could the other person (let’s call him A) the Service Desk wanted to refer me to. Now I wait for the new person, A, to call back. At least I confirmed the first one still works there.

Since all I’m asking is to confirm a date still in the future, which was supposedly set in January, this is a disturbing lack of response.

And now Sierra is down. What the hey?!?!

Perfect Storm

Later Wednesday morning:

So, apparently III is having access problems with Syracuse on the network. So now I put in a call on that as well, since we can’t get the Sierra desktop app to connect.

Then I had a scheduled meeting to go to.

Meanwhile, my domain name change got referred to A, somebody new. Who apparently did NOT read the entire ticket, which said March 20th, and that I just wanted confirmation that it would happen on March 20th.

And who then went ahead, while I was out at a meeting, and changed our domain, set the _replace function, and installed the certificate.

Today. Immediately. With no preparation or coordination on our end, because we were planning on March 20.

That’s right – we are now libcat.uafs.edu but it doesn’t do us any good – almost EVERYTHING going through the server is broken. The WAM is useless, still no Sierra access, and — wait for it — the I.T. person on campus here who was going to help with this domain change IS OUT OF TOWN. I had to go over to the Service Desk in another building just to find that out.

Slow, deep breathing. Right.

I decided to not confuse III by trying to change back — they’re obviously busy enough as it is. We’ll try to rush this through with another one of our I.T. people. He’ll have to update the DNS (Domain Name System) so it recognizes the new domain name, and that has to propagate through all the others on the web. Plus anything else they need.

Then, IF we can finally get to our staff Sierra app, we can start testing to see what databases need changing in the WAM addresses (it seems some of them need hyphens added, but we have to have access to check).

Meanwhile, we have no circulation, we have to do a workaround to even use a limited number of databases from on campus… a perfect storm of impairments. At least the OPAC is still working online, for reasons I don’t know enough to understand. And I can still telnet in, for all the good that does me.

Yet later:

Finally our I.T. was able to get a good person on it, and he redirected our DNS to the new address. So:

  • In the Sierra app, update iiirunner.lax to the new address.
  • On the command line, enter ipconfig/flushdns to clear the DNS.

Start Sierra and now it works. The catalog is still working. BUT – the WAM is not connected to the databases, which was, after all, the primary reason for doing all this in the first place – so we could avoid the darn security warning pages that don’t like the iii.com SSL certificate.

Apparently our WAM is still putting the old address into the links. However, if you correct to the new address manually, you get:

This site can’t be reached

0-search.ebscohost.com.libcat.uafs.edu’s server DNS address could not be found.

So, update the Supportal and see what happens next.

Meanwhile, all our students studying for midterms are unhappy.

March 10 Friday

Looks like the libcat.uafs.edu domain is propagating through all the DNS servers on the web.

We got the off-campus databases working, but not the on-campus access. Our Ebsco Discover search through the WAM is still down, but we rigged a link to not go through the WAM and on-campus people can use that.

Then, we got attention from A on the matter, as well as the person (“B”) who originally recommended the domain change, and we got the wildcard put into our DNS which solved the on-campus access through the WAM: *.libcat.uafs.edu  We probably would have discussed that in advance of the change we expected to make on March 20.

Now, we have a change for the Discover search in the script on the home page, and that will be solved. We hope.

I’m still plowing through updating catalog links to ebooks. Past experience was that doing much more than, say, 50,000 a day frightens the server, so I’m doing it in chunks. Incidentally, we also had to update our 962 fields for linked images — that’s where, among other things, we put our donor/honoree bookplates.

So we seem to be coming out of a nosedive. I did a talk for the CAST college this morning, pre-changes, and this gets around the problem I had.

We may have to flushdns as I mentioned above, but we’re almost back.

TGIF!

March 15 Wednesday

Monday we seemed to be finally about back to fully operational. I got the last of the ebooks done Tuesday. And III has sent a couple of quality review requests for all this. I can hardly wait to see what I’m going to tell them….

Kudos to our I.T. person on dealing with the domain change in emergency mode!

As of Tuesday, I finished updating all the ebook records in the catalog (all 230,000 plus of them).

And today, I got the new director up on Sierra. Since Sierra installs with its own Java, there was a popup permission to give for that, which was hiding behind the Sierra logon screen, which is what was blocking it from going on.

And now we can look forward to training on our new ILL software from OCLC, which goes live here on March 31.

March is coming on like a lion, right – like Scar in the Lion King.

Scar in the Lion King

 

 

 

Advertisements

Sierra 2.4 so far

[updated 2017.1.26]

So the Melbourne, Australia office updated our Sierra to 2.4 last night.

This has a lot (but not all) the functionality of the desktop app in the new web access version, as III moves away from a Java-based app.

So far, I’ve noticed that Create Lists does not let me scroll lists as easily. The print function is not ready for prime time; I cannot configure the printer through the web printing as I could in the app, especially for label printers. I haven’t tried receipt printing yet, but that will probably have the same problem, so looks like we cannot

The print function is not ready for prime time; I cannot configure the printer through the web printing as I could in the app, especially for label printers. I haven’t tried receipt printing yet, but that will probably have the same problem, so looks like we cannot use that at the circulation desk as I had hoped.

More fine tuning needed.

We don’t use the built-in macros so that limitation doesn’t really affect us. We use a third party program called Keyboard Express (a shareware product we licensed years ago) which fills in what we want, or handles keyboard commands, and that still seems to work.

Following the holidays, I expect to change the domain to libcat.uafs.edu and get a certificate and — we hope — get away from the https problems the WAM is having with our online vendors.

Update: well, due to a perfect storm of delays on both sides, III didn’t change the domain yet, so we are still struggling with the popup warnings and blocks for some services through the WAM. We’re not alone in that, of course.

On the bright side, we can now do most routine operations (aside from printing) through the web service. This has come in handy already for a staff laptop which didn’t want to load the Sierra desktop to work on inventory in the stacks.

Sierra Preview

Okay, continuing our moving to hosted servers and Sierra from “Enter Sierra“.

[updated with link]

Monday July 13

We were scheduled for Tuesday, but III got us up early.  Hurrah!

I had to go into the Admin using my browser, and set up my login.

Then I installed the SDA (Sierra Desktop Application), and loaded it.  It took much longer to load the first time than it did to install.  After that, it’s faster, although it might seem slower than Millennium due to the lack of popups indicating something is actually happening.

Look but don’t edit, basically, at this point.

I copied over from my User name to the others who will also be administrators, but I still had to go in and do Applications and Permissions for each of them.  After that I carried around a flash drive with a batch file to install a version of the SDA configured for us.

Doing Permissions is, frankly, really clunky.  Two boxes with lists of permissions, and no click/drag — you have to narrow it down to the specific ones and then copy over.  Sometimes easier to copy a batch and then except out the ones you didn’t want afterwards.

They are grouped, at least, by general function, but that still leaves a lot of stuff to weed out for each individual.  Due to our small staff, we have a lot of overlap (we all do some evening and weekend circulation supervision, for example).  In our case, there can be a lot of exceptions needed.

Monday, July 20

Phone conference with just the director, the committee librarians and me, and our III project manager.

I proposed, and everyone agreed, that we could go live a week early.  III was happy (although I think they wanted the conference in part to be sure everyone was in agreement on it) to comply.

We will go live on Wed. 22nd (ahead of our original date of the 28th).

Why?

We have a small staff and a limited number of workstations.  So we got the Sierra Desktop App installed quickly, and people looked, and said that’s nice, and went back to their regular work in Millennium.  What else could they do?  Until they actually get to work with Sierra, there’s only so much you can get from the Preview phase.

I need to clear the Headings report and the Web Management stats, since they don’t transfer over, and then we’ll be down Wednesday morning at 8 a.m. to whenever they finish.  Estimate is 4 to 6 hours, but might be less.  Since we removed the Acquisitions module several years back, it wasn’t a factor.

We still don’t have the reference database access in Millennium.  I changed the command line for the icon to use the domain name uafs.iii.com instead of the digital i.p. address.  I also changed it in the .lax file.  Still no good; it cannot reach the server.  III also has the same problem when they try, although we can all reach the regular catalog.

Wednesday, July 22

In progress

It’s Go Live day, and they started at 6 a.m. Pacific time, which is 8 a.m. Central.  I got an email confirming so it should be in progress at this moment (8:18 a.m. CDT).

We’ve had lockups on the SDT software on several of our PCs so far during the initial startup (not the installation itself) during “loading jacob.jar”.  Most likely due to not having administrator rights; our I.T. is very reluctant to let staff have those without jumping through a few hoops for permission.  I’m working on getting that fixed.  Everyone who has admin rights seems to have gotten on okay.  We had a similar problem with Millennium software. Just installing with admin rights does not insure the software works; it may need security settings adjusted.

Waiting for it to complete, I’ve printed out checklists for Circulation and Serials, which are pretty short.  I’ll do the others needed.

We’ll keep Millennium icons on for the people who handle our reference database, which we call the Regional Index.  We use that for indexing local periodicals.  Otherwise, everybody should be working through Sierra, although there is a way to call up Millennium if necessary (see “How do I access Millennium after my library is live on Sierra?” on CS-Direct).

About 11 a.m. they got us up — 3 hours, not bad.

We got through the checklists quickly.

I’ve been deleting the old Millennium logons, and as we get to it, we’ll delete most of those old icons unless someone is using it for the Regional Index (reference database).

It seems that the “Dashboard” concept is not really being updated and supported, as I had only one III widget which didn’t work.  People like to customize with rotations of cat pictures and scenery too much to be tied down to something like that…

Wink_superman

Monday, July 27

Plus side, the Saved Export now saves and uses the delimiters I’ve wanted for years, so I don’t have to change them.  Con is that I had to save the entire Export again to get it to work correctly.  Small price to pay.

Some things we find in Sierra may have actually been done in versions of Millennium after 2009B, but the features are new to us.

Transactions File

Transactions file — long my nemesis, as doing large Global Updates to files (usually ebooks) had to be spread over multiple days, so I wouldn’t overload the transactions file and require a backup and clearing the temp file.  I noticed there is no more transactions file percentage shown and asked about it.  Hooray!  Written immediately to data, so no more temp data waiting to be written.  This will free me to make those large changes as often as needed.

Tuesday July 28

Working on the details now from the migration, and reporting to III using the BaseCamp site.

Still no access to our reference database; III says they are working on it.

Finding some user permissions are not enough; I have to set Options and Settings for people for them to get to the right functions.  Example would be the webmaster and web options functions, which I needed to define for the /live/screens area.  Just a variation in Sierra, I think.

Bookplates

I did a Global Update for all the links in our media files, primarily for our bookplates (posted here). For unknown (as yet) reasons, all the images in the record displays switched to tiny thumbnails.  You can still click on them and get the larger version, but I’d rather have them show up as they used to.  Put in a request on how to fix that.

[update: got it.  Needed to change the css:

.bibMediaTable td img
{
max-width: 60px;
}

So I changed it to 200px to override the default css, and it works fine.  Since the height can vary, I left that off.

Inventory

It’s been — literally — years since I set up the Serv-U software and inventory process, and it’s done all right for us.  However, I’ve asked for a step-by-step for getting the data from a workstation here to the hosted server.  I have a file which should work, but ftping the file to the server is a hangup at this point. That’s another request.  (And no, we aren’t planning to buy CIRCA; this is expensive enough and we wouldn’t use most of CIRCA’s functions anyway. We just need the inventory function.

Tuesday August 4

Progress:

The reference database a.k.a. Regional Index is now accessible via Millennium.  So, that’s done.

Pending:

Still working on the inventory problem.  We have a file, and it has to FTP to the hosted server, and that’s the trick.  Our I.T. person says he sees us open an FTP to the hosted server, it succeeds, and then nothing is transferred, and then it shuts down the channel.  Which is pretty much what shows on the screen.

The odd part is that my external address is refused a connection.  Our internal address for my workstation appears to work.  Since — I freely admit — the whole business of dealing with internal versus external addresses when going off-campus is above my pay grade, I have to leave it to III to see what’s the catch.

Our I.T. person said that the port should be 22 (not 21) when using SSH access instead of telnet, but changing that in Serv-U and having III enable it doesn’t seem to help.

I’ve also found that sending records to Ebsco Discovery Service (epnet.com) is not working.  That’s been kicked over to their tech people.  That’s really on EDS, I think.

So, closer and closer.

And now the engineer is on vacation, so someone new at III is working with us on the inventory thing. The problem is, this technology is so old (in computer terms) that nobody there seems to really know much about how it’s supposed to work, so I just had to do a step-by-step and send a copy of Serv-U to the new person.  Maybe it will help.

Wednesday August 5

Printers

Okay, new tweak but a minor one.  We use the Star TSP654 receipt printers at the front desk.  They weren’t cutting the receipts, and the configuration was off.  So, I had to play a bit to find a new equilibrium for all the settings, both in the printer properties and the Sierra printer selection.

Once I managed that (I hope!), I updated the online manual, which I’d been planning to move to LibGuides eventually anyway.

It seems that some settings transferred from Millennium, but until they are redone in Sierra, they don’t necessarily work.  Kind of like the Saved Searches and such in Create Lists.

Inventory

Okay, new III person is working on it.  We’re trying to get port 22 open on both ends to FTP files.  He has to put a call in to enable at their end, and I’ve asked my I.T. person to doublecheck at our end.

Friday, August 21

Still waiting on our I.T. people to work with III on the inventory problem.

Bear in mind, we are in the first week of the semester, they had a whole new building to equip plus a new campus web site, along with all the last-minute stuff that usually has to be done to start the fall semester.  So, I’m trying to cut them a little slack.  III is being understanding about that.

I notice that the OCLC importing takes a moment longer before getting a confirmation from the server.  So my usual quick reaction ends up cutting that off, and then I have to check to be sure the record actually made it into the catalog.  So far it has, but I have to remember to slow myself down — the actions list down the Connexion popup and that’s been when I hit the key, but I need to pause there and wait for the confirmation.  Minor change in procedure.

The Create Lists is running faster, we notice.

Wednesday, August 26

Well, the inventory situation is more complex at our end.

This may not be something that anyone else has to deal with (nobody at the Arkansas IUG meeting still does/ever did inventory using the old text-based method).

In order for this to work, I have to make my computer an FTP server.  I used our licensed version of Serv-U, which I configure to handle my IP address and that of the III hosted server.  I load that so my computer becomes an FTP server, and then I open a text-based session using putty into Sierra.  Then I tell Sierra (now client) to come get the inventory file from my computer (now server).  Several steps, but not that complicated, right?

Getting the concept over to our I.T. people, however, took somebody coming over and actually watching me go through the steps.  This has been slightly complicated by having to change out my trojan-infected computer, which occupied the first 2 days of this week.  However, while getting a new setup and working on this problem, I got (I think) what I needed in the first place, a static I.P. address internally and externally.  Normally, the library pulls from a rotating group of internal addresses and maps all of them through one external address, which means that I can tell Sierra “come get it” on one address, and when Sierra tries, it ends up with a different address, provided I convince our people that Sierra actually has to be allowed in.  So I have to have a static (non-rotating) address that always stays the same.   The fact that Sierra has to come back into my computer to find the file was another sticking point, security-wise.

Now I have that.  The problem now turns out to be that I had two I.P. addresses all along.

I learned that I also have an I.P. address that connects to our Blackboard system for controlling the library’s door locks, along with some software for that.  This may explain why I have trouble remoting in to my computer from off-campus to change the door locks (for snow closing days, for example) — at any given moment, I may get the Blackboard I.P. instead of mine.  I have to keep trying until I get through (or give up).  Another person who also has this control has the same problem.

And guess which I.P. address Serv-U is defaulting to when trying to FTP my files.  In spite of my specifically denying it in the configuration.  It displays in the Serv-U window along with my internal address, mocking us.  Curses!

But, at least we have somebody working on that.  And it might lead to a solution to having to make multiple attempts when trying to log in remotely.  We can hope.

As I said, not exactly common for most people, but if anybody else uses a Blackboard setup to control anything on their computer, it might introduce a second I.P. address into the situation.  I gather that might not be the only way to do that, but it’s what was set up on this campus.

Sideways progress, but I’ll take it.

Tuesday Sept. 8

I’m just going to say it flat out.  III was incorrect when the migration team told us that switching us to the iii.com domain would allow their SSL certificate to cover our databases. The way an systems person has now told me (after I asked for a certificate update), it doesn’t cover uafs.iii.com, only iii.com, and therefore, we will continue to get popups.  The engineer indicated that other libraries handle their own certificates on their own domains, the way we used to:

The cert is for *.iii.com; the browser wants to see a cert that covers 0-www.jstor.org.uafs.iii.com, and hosted services is not going to add a SAN entry to the wildcard cert for each library’s proxied domain. (Assuming the hosted customers wildcard cert even allows the addition of SANs, which it may not.)

Most hosted libraries that use WAM for a number of resources do not use the iii.com domain, and manage their own certificate.

In a review of the services on the migration, I indicated a serious markdown on satisfaction due to this point. III needs to have a knowledgeable systems/software person on the migration team to counter misinformation.

In shorter terms, I am seriously ticked off about this.

WHAT THIS MEANS:

We are going to continue to get popups on security, and will need to teach students to click on “Advance” and to go on through to the databases.

Short of a massive change, all over again, to all our uafs.iii.com links in databases and ebooks, and doing our own certificate updates again, we are going to have to inform users about this and tell them to go through the steps each time they use a database or ebook.  It should only happen at the start of the session for that vendor, at least.

My recommendation to use the iii.com domain was based on III’s misinformation, which was apparently based on the migration teams misunderstanding of the capabilities and previous experience of other libraries.

Sunday Nov. 29

Been out with surgery for a while, but I see that we finally have our inventory functions working!  Took a lot of coordination with our overloaded I.T. people and III, but that’s the last big obstacle.

Other than the SSL problem, of course.  We’re going to have to work out what we want to do about that.  III was not interested, last time I emailed, in adding an SSL certificate that covered only our server — at least, while we used uafs.iii.com as an address.

Final Conclusions

III is committed to Sierra and will continue to upgrade and maintain it, for the immediate future.  Millennium is likely to have declining interest for them.  So, going to Sierra is pretty much the path to follow if you expect to stay with III over the long run.  But, you knew that already, right?

Hosted systems are more cost-effective on Sierra due to needing two servers.  This is especially true for anyone with limited or no I.T. staff. It also meant our server stayed up while the campus changed to a new web pages arrangement (with all the usual complications of updating an entire campus web site system).

If you get hosted, however, the SSL certificate for *.iii.com will NOT work for browsers accessing your name on iii.com.  They just don’t seem to recognize it as the same thing.  So, to avoid this, plan on arranging for III to use your own name (probably not using the “.iii.com” address) and installing your own SSL certificate, with all the hassle that entails.

Just my experience and take on the matter, for what it’s worth.

Next post on this is Sierra Aspects.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Enter Sierra

So, we’re moving to Innovative Interfaces Sierra, hosted at the III server farm in Syracuse, New York.

I will be updating this as we go. [also updated 2017.1.23]

Motivation

We were notified that our aging III “turnkey” server, a Sun V240 running Solaris 9 (which hit the upgrade wall at version 2009B and no more upgrades to Millennium or other software were possible), needed an upgrade to our security, or it would jeopardize the campus being able to use credit cards.

I.T. is required to patch or update any servers with a rating of 4 or 5, that are accessible through the internet. The libcat.uafs.edu is one of those servers that needs to be patched or updated. According to the report, our OpenSSL is rated as a #4 and needs to be updated. In addition, “SSLv2 and SSLv3 protocols need to be turned off and the server needs to only use the TLS protocol.” (Is that clear to everyone? Then I don’t need to explain it, good.) There are other minor vulnerabilities at this time.

The catch is that we cannot upgrade due to the age of our software, and we cannot upgrade the software because of our outdated hardware — III is not maintaining a newer version of their software on this platform (Sun V240) on a newer version of Solaris.  This is our second server model since 1999.

So, we have to move on.  We don’t have the programmer(s) to handle an open source system, so we’ve been looking at OCLC or III’s Sierra for a changeover or upgrade for a while now.

Using III’s hosting was not cost-effective for a single server system, as we calculated — we could pay for a server and still get by for less, as long as III handled the service contract.  By moving to Sierra, however, which needs two servers, it then becomes cost-effective for us to have III host our catalog rather than trying to do it ourselves.  We’re not that large a campus, and our I.T. staff is working hard already, so let’s make it easier on them.

III offers the option to either stay with our present name libcat.uafs.edu, which means we would need to keep buying (and often updating) our SSL certificate, or changing to [something].iii.com and letting them deal with the certificate updating.  They are hosting larger campuses already, so they should be doing any needed updates for their more extensive databases already.

Warning: the decision to change to the iii.com domain did not work out – the SSL certificate does not cover us adequately. We are changing back to libcat.uafs.edu in spring 2017 and adding the WAM replace function along with an SSL certificate.

We’re also going to avoid the hassles of backup for the server (on little tape cartridges all these years) and let III start to do all of that.  Again, something else our I.T. staff won’t have to deal with anymore.  They didn’t have people to do backups on weekends and holidays anyway.

Fortunately, most of the computer workstations were updated when we moved into the expanded building, so the processors are fast enough with sufficient memory and such.

Our newest professional staff member has worked with Sierra before and is happy we’re moving to it, so we have an insider already who’s been through the conversion before.

Sierra is the future for III, and will be where they are concentrating their updating, so this was pretty much inevitable if we stayed with III.  At this time, we’re not ready to change to OCLC (as they presently exist) or another system.

First Teleconference

June 16: We had a teleconference with the III people handling things at their end, plus librarians and an I.T. representative at our end.

I asked them about going with the iii.com URL which, it turned out, they had already set.  Since we’re going to have to change all the I.P. addresses anyway, we want to update the name to uafs.iii.com .  They got a little ahead of us and created warkc.iii.com (based on our old name, since we started with them as Westark College).  We’ve asked to change to uafs to make it less confusing; we’ll see if they can manage that.

We did get the new I.P. address for our application server.  We go through that to a database server.

The sequence for us will be:

  1. Move to the hosted servers in Syracuse, N.Y. with our existing 2009B version of Millennium.  We’ll change the Millennium software on staff PCs to the new I.P. (me and maybe I.T.), and the links on the library web pages and databases (another librarian handles that) will go through the new hosted system.  I’ll need to change all the 856 links using libcat.uafs.edu to our new URL (whichever it ends up being).  This is set for July 7.
  2. Upgrade to version 2011, which is the closest version of Millennium that can convert to Sierra (no use upgrading more than that since we’re moving to Sierra at the end of it, anyway).  Do a quick bit of testing on that.  This is set for July 9.
  3. Sierra will be “seeded” and then we’ll be able to access the Preview version of that.  It should be ready by July 14.
  4. While on Preview, we’ll get the permissions and such set up for the staff along with installing the SDA (Sierra Desktop Application).  We’ll then have both Millennium and Sierra software for a bit.  Actual access will be read-only while any real work is still done in Millennium.
  5. We’ll go live on Sierra full time and use only that.  That will be July 28.

Since we’re relatively small, our down times for the changes should be only a couple of hours.  This will be during Summer II, which is a really thin semester, so it shouldn’t be a huge problem.

The time frames were expressed as normally being longer than we really need.  Since all this is being done on the hosted servers, I think it’s actually simpler and faster than having to deal with us remotely on local servers.  (On the other hand, people in California are dealing with servers in New York, if you consider that “local” for them.)  So our dates are somewhat compacted, which will get us in shape well before Fall classes begin on August 17.

Basecamp

III is using Basecamp for project management software.  We’ve gotten invitations (June 18) and I’ve logged in.  The interface looks nice.

I had already read the Sierra preparation information and created our circulation Statistical groups, so that’s done.  The other thing to do seems to be at III’s end: opening ports on the Sierra server.  I’d sent info on that to our I.T. people in an earlier email so they can see it’s not their problem at our end (III just gave a manual reference).

uafs or uasf?

Well, after a slight glitch, III switched us to uafs.iii.com.  I didn’t think about the fact that it also meant that their help software, CS-Direct, needed to change our login from the old warkc to uafs but apparently that is synced to make it easier to keep track.  Which happens to be the reason we wanted it changed to match our current acronym rather than the old one for Westark College (which we haven’t been since 2002).

So, I got an email that our new login would be uasf.  That’s right — the last two letters transposed.  And it wasn’t just a typo in the email; that was the actual login.  So I gently asked if that was intentional (maybe “uafs” was taken already by somebody?).  No, it was a typo in the setup and would be corrected  (and was, promptly).

I told the coordinator that I was glad, as I hadn’t been looking forward to telling the Chancellor we had to change the campus to “University of Arkansas – San Francisco”. >;-)

So we are now going to be (correctly) using uafs.iii.com for our URL.  Progress!

Our webmaster/database librarian is getting the word out to vendors on our new I.P. address, which many of them may just add as another option to our access.

The next big milestone at our end is probably going to be the migration to the hosted servers on July 7.  While that’s going on (about 2 hours, they figure), we’ll need to go around to all the staff workstations and append the IP address to the properties in the Millennium icon to redirect it.  Then we restart by connecting to the hosted server in Syracuse, and we should be back in business, still on release 2009B.  On the 9th, we upgrade to the 2011 release.

QUALYS

I mentioned that our campus I.T. people wanted us to upgrade somehow due to security.  It turns out that they’ve had a security outfit called Qualys scanning campus systems as part of this.

And we’ve been getting “all ports in use” ever more frequently.  This has been going on for months, but it seems to be stepping up this year.

Finally III managed to track down a group of I.P. addresses that seem to come from this company, which I then asked I.T. about.  Oh yeah, we have them scanning you for the security, I was told.  We just didn’t tell you before.

Well, that might explain at least some of the resources being tied up.  Since our system is not going to change before we finally leave it, I asked if we could get off the scan, as it seemed to be overloading us often.  That’s been done.  So far, no more “all ports in use” messages.

Once we can confidently say we’re on the hosted server and tested okay, we can shut down the old local libcat.uafs.edu server and take it and its outdated security off the campus network.  That solves I.T.s security standards problem.

Preparations for web pages

We have a campus home web page and related pages, on a campus server.  This links to our III server.  Those pages will need to be updated immediately after we migrate to the hosted server.  Our webmaster will be busy with those for a bit.

I’ve gone through the other web pages which are still on the old server.  Updating these is a little easier, as instead of libcat.uafs.edu/screens/whatever.html, I can reduce the link to /screens/whatever.html and the server will search for the page on itself, whether local or hosted.

So, making that change to most of the links leaves only a few pages to fix after the migration.  I have those marked on my printout so I can head straight for them ASAP.

Migration Day, July 7

So, it’s the big day to switch to the server in Syracuse.  I’m told it will take 2 to 3 hours, perhaps more.  We’ll end up with the same thing we have now, only running on a different server.

There’s a notice on the library home page that access to databases and the catalog will be down for several hours.  It’s the start of the Summer II semester, which is about as slow as it is likely to get during an actual semester.

While this is ongoing, I’ll be going around and changing the command line in everyone’s Millennium:

C:\Millennium\iiirunner.exe ip=our new IP address

By adding the IP address to the command line in Properties, we connect there without having to remove and reinstall Millennium everywhere.

That’s not all — we have to change the Export option in OCLC Connexion to the new IP address as well, for everyone that has that, which is a smaller group.

Once we’re back up, I have the last few web pages to update.

Following migration, July 8

Well, that could have gone a little smoother, frankly.  But we have Millennium up again.  However…

We took longer to get it done (we didn’t get the original time frame from an engineer, for one thing).  Also, the fact that we had a reference database (originally called a community information database) may have been overlooked by the other project people.  That was extra work for III.

The problem now is that the Web Access Manager is still not functioning.  If we delete the “0-” and “libcat.uafs.edu” from the URLs, we can reach databases on campus.  However, substituting “uafs.iii.com” in there still doesn’t work… yet.  That’s a project for the engineer to fix today, and then we’ll be beck.  (Sorry – “back” — my Terminator accent kicked in.)

This is apparently due to changing the domain completely to uafs.iii.com which actually means more work at this point, even though it leaves us less vulnerable to problems later.  Apparently most places just alias their old address to redirect over to the new one, whereas we wanted to go directly to it from everywhere.  That sames a micro-second on connecting and having to go through other computers to disguise the new address with a redirect, so technically it was the better way to handle it.  It’s more effort up front for the engineer, however.

While that means that changes elsewhere (say on campus servers) in the future won’t “forget” to include that alias kludge and have to be fixed if/when they occur, right now III is trying to get all the old libcat references changed over, and something connected to the proxy server (WAM) is not correct yet.

The engineer was working late last night and planned to come in early this morning (California time), so we’re hoping his dedication will pay off shortly.

We still have a software upgrade to 2011 Millennium scheduled for Thursday morning, so I’m hoping we get this all straightened out today.

Thursday July 9

The upgrade to version 2011 has been postponed to Friday.  III’s decision.

The engineer was scheduled to work on another library yesterday, so couldn’t clear everything up from the migration, but we did have the databases up again for the most part.  The new address needed to propagate through all the DNS servers for the various vendors, apparently.  Our serials librarian will be checking all that.  So, good for that.

Also, we had some odd glitches with the CSS, but that has been tracked down and resolved for the most part, so things display more or less properly now.

We still get a “server not responding” error when we try to log into our reference database.  That’s going to take a bit of tweaking by III, I suspect.

Yesterday I began the 856 URL change for ebooks, etc., in the catalog.  The WAM needs the libcat.uafs.edu changed to uafs.iii.com in all those links that have it go through the proxy server, so I’m doing those in 10,000 record chunks at a time.  I don’t bother to select or sort — I just look for that in the 856 and pull up another batch of records.  If somebody needs a specific one I haven’t done yet, I can nip in and fix it individually, but it’s pretty quiet right now, so I’m just plowing along.  I probably can’t do them all right away; the transactions file would fill up.  But I can do a good number of them daily.

We also have to go through our LibGuides and update any catalog links.  I got mine done pretty quickly.

We are having email problems with overdues, and courtesy notices — they don’t seem to be going out.  III is working on it.

July 10, Friday

III is still working on the overdues/courtesy notices email problem.  The hosted server cannot print directly to the printer that used to handle server stuff, but works fine when we select “local printer” and designate it.  (No, most of us don’t have attached printers, it’s a cost-effectiveness thing for campus I.T.) So we have that working, but all the notices print because they can’t send them via email.  Fixing that is now a priority.

We don’t have Web reports, either, but that’s a Java thing.  And thereby hangs another tale…

We have SCT Banner for the campus management system.  We must use Banner.  The catch is, SCT is behind on updating Banner for use with the latest version of Java.  Therefore everyone gets “outdated” notices on Java, and has to be blocked from updating themselves to a newer version of Java that won’t run Banner.  Follow so far?

Millennium also runs on Java, and we have to deal with I.T. on letting us run a separate Java for that regardless of the other Java on each workstation.  That’s a long-standing conflict here.  I’m not too concerned about that until we move to the 2011 Millennium, frankly, as I’d rather not deal with that all over again for a newer version.  It might resolve with the upgrade.

I’m waiting to find out if we have the 2011 upgrade delayed on account of the email issue or not.  Oh, it seems not.  III hopes the email problem may be resolved by the upgrade, so we’re going ahead, and a half-hour early at that, at 9:30 instead of 10.

Well the upgrade was quick.  But the email problem was not fixed, and we still cannot get to our reference database through Millennium.

I notice that Chrome does not load the Java for Web Management Reports but IE does.  Go figure.  As long as we can get to it somehow, I’ll settle for now.

Monday July 13

III kept working Friday after we went home here (thanks to time zone differences) and solved the email problem.  So hurrah for that.  The engineer is still working on the reference database, but that’s not quite as urgent.

III still shows Sierra Preview scheduled for tomorrow.  Whoa!  They did it early.

Next post will be “Sierra Preview“.

 

Evolution of a code system

Fair warning: highly technical library cataloging talk in this specific post.  May have soporific effects on non-catalogers.

When the Library here first got OCLC, we were assigned 4-character codes for types of materials.  OCLC used these codes (in part) to assign the ‘above the call number’ indicators like “REF” for Reference materials, or “VIDEO” for videocassettes, to show where materials were shelved in the building, so they could print catalog cards for us.  (Yes, I’m that old.)

The codes looked like asza, aszb, aszc… you get the idea.  Those codes were for Nonfiction (circulating), Fiction, Reference, and on.  In time, we had to add more codes for new materials that hadn’t existed earlier, such as Compact Discs and DVDs and websites.

Years went by, we automated, then we changed automation systems.

Once we got the Innovative Interfaces Millennium system, we assigned codes more or less in line with these.  We had codes for bibliographic records and codes for item records (among others).  If a book had a CD inside, for example, then the bibliographic record had a book code, and there was one item with a book code and a second item with a CD code.

I had wide categories (Books, Serials, AV Media, etc.) in the BCode1 group (here called BGeneral) in the bibliographic records.  Item records (1 per barcoded item) were attached to bibliographic records.

The location codes in the item corresponded to the OCLC 4-letter codes (asza meant Nonfiction – 1st East, meaning 1st floor east side, for example).

We had BCode2 (a.k.a. here as BType) and, in item records, ICode2 more or less matching it.  For example, we needed to have a BType of just Reference, but the item records ICode2 (and locations) had to be divided into Reference and Reference Oversize as separate locations.

We had codes scattered along the alphabet as they evolved.  If you wanted all the audio-visual media, you had to ask for this OR that OR that OR that OR that OR… it was a chore to set up a search.

Then I recently learned from the IUG (Innovative Users Group) elist that the symbol for ebooks, which Innovative had some years back designated as “@” (at) was now a problem with their newer software, which didn’t read the @ but considered it punctuation and therefore equal to blank.  This meant the Preferred Searches function couldn’t handle ebooks.  I needed to change the symbol for ebooks in BType and ICode2.

And while I was at it, since it was July and we were starting a new fiscal year and statistics, if I wanted to change the codes, this was a good time to do it.

Result: I revised the codes, and the codelist.

First, I lined up all the existing codes in a spreadsheet, and got the BType codes and ICode2 codes all matched up.  Some codes (such as ICode2 for Ref Oversize and Indexes) didn’t exist separately inside BType for Reference (they all just got coded BType for Reference), and didn’t need to be created.  Some ICode2 codes such as Scores and Microformat Books didn’t exist separately and didn’t need to be created, and so on.

In Millennium, we mostly use ICode2 codes to take counts for inventory purposes.  Since we don’t need to barcode ebooks (for example), we don’t bother to create item records for them, unless we need an item record to function within the EReserves system (if an instructor put an ebook on his/her Reserve list, we would need to create an item record — without barcode — just to attach to the instructor’s list, but not to count on inventory).  So, ebooks are counted by the BType for ebooks rather than an ICode2.

Then along came the titles where we had both paper and ebook formats.  So, we put the ebook code in BType (where ebooks are counted) and the paper type in the ICode2 of the item record containing the barcode (where the paper copy is counted) so both versions are counted in their respective material types.

Anyway, I wanted to group the codes better, so that instead of “this OR that OR that OR that” I could search for codes in the range “this to that” and have an easier time setting up a search.

I also cleaned up a few odd problems, fixed a few records with wrong codes, and separated our ebooks into fiction and nonfiction.

I created a file for each code that was going to change and used names with “btype= w > d” to indicate that code w was going to become code d.

Then I revised the codelist, the web manual pages, the saved searches in Millennium, the saved templates for records in Millennium, etc.

Someday I’ll probably have to do it all over again, but for now, I think this arrangement will work for us a while.  If anyone setting up a system finds anything useful in this, that’s nice, too.

ILLiad and Canons

I spelled that correctly.  Really.

It’s “Canon” as in the manufacturer, and OCLC’s ILLiad interlibrary loan service.

After long consideration and talking to Innovative Interfaces people, we’re moving away from the Innovative Interfaces ILL module, such as it is, and setting up ILLiad.

I’d gotten a Canon MX-700 all-in-one to replace our old fax machine earlier.  It seemed to be doing well, so when we needed a color printer to handle the occasion ILL that we need to print, I just got another — on sale, of course! — since it could double as a scanner with an ADF (Automatic Document Feeder).   Inkjets are expensive for cartridges, but we don’t print that much color from it, and send black&white to a laser printer instead.  They could both use the same cartridges.

When it came time to train on ILLiad’s “Odyssey” function, which scans in documents to lend, the Odyssey software crashed.  It wouldn’t even open — just crashed the ILLiad software completely.  Apparently it didn’t like the Canon MX700 driver at all.

Hmmm.  So, I installed the driver for our older, less reliable Epson 4490 (they’ve been dying on us at an accelerating pace).  Then tried it without the Epson attached, but kept the Canon MX-700 attached.

Now, Odyssey came up, said it couldn’t find the Epson (we told it never mind) and Odyssey opened.  Then I chose the Canon from the list of available scanners.  And we were in business.  The trainer couldn’t explain it.  Did the same thing on another computer.  Install the Epson driver to find first, and it came up.  Canon only, it crashes.

Now we needed a scanner (just a scanner, no ADF, no printing) for another ILL workstation.  I had just gotten in a Canon 8800F so I put that on with the 8800F driver.  Try to load Odyssey and — Crash.  Try something else.  Crash.  Crash.  OCLC claims it works with any TWAIN scanner.  Crash.  Consult, check all the suggestions off.  Crash.  Crash.  Install the Epson driver.  Crash.  Install the MX700 driver.  Crash.

The librarian in charge of ILL finally worked it out.  Turn the Canon 8800F off first, then load Odyssey, then turn the Canon back on.  Then Odyssey seems to be happy with it and lets you change to the Canon.

Scanners are notoriously wonky creatures, and OCLC software is very particular, but at least we have a workaround.  If anybody else has an explanation or better way to do it, I’m open to discussion.

BTW: Dell PCs using Windows XP Pro, USB interfaces.  I love USB interfaces because they allow you to switch equipment so easily.

tabs in the catalog

Working on the catalog display in Innovative (III) today and making these notes to myself.

I originally used the May 2007 set downloaded from III, with some modifications I picked up at IUG, for the version I brought out in August 2007.

The campus standard HAD been to accomodate 800×600 displays, and I didn’t want people using those to go from the campus pages to the library pages and find themselves suddenly running off the side of the screen with the catalog.

Since we are now no longer restricted to the 800×600 display (with the wide margins left and right), I’m reconfiguring the pages for 98% width (just a 1% margin on each side — I think it looks neater and less crowded than 100% across the page) of the screen in 1025×768 resolution.

That leaves a lot of stuff sort of weighing down the left side. All the tabs, for example, start on the left, and don’t go very far across in many cases.

So, I decided I needed to change the width of the tabs to spread them out a bit. The catch is, the tabs normally on mainmenu.html, for example, are using the div class “mainActiveTab” with “menuActiveTab” and InactiveTab, and those have only one size.

However, the div class “helpActiveTab” has “helpActiveTabMedium” and “Large” and seem to work just as well, so I’m replacing “main/menu” with “help” div classes. (It’s easier than adding to the CSS for “main/menu”.)

Then I changed the size to all medium tabs. Spreads further across and balances the look better, IMHO.

I’ve also taken the frame with the Quick Links and moved it over to the far right 20% of the page, and reset the percentages to 80% search and 20% Quick Links frame, now that I have the additional room. More balanced, again.

Tests okay.