How To: Blackboard Learn Updates

Posted on Updated on

BBLearnAs the System Administrator for our Blackboard Learn LMS I am tasked with updating the application and keeping it functioning properly. In doing these tasks I use a Development Instance of Learn to make sure that Building Blocks (B2’s) work properly when applied, patches work correctly as in the YouTube patch that was recently released and Cumulative Updates such as April’s Cumulative Update 5. Using the Dev site makes for great practice and the ability to test things that I wouldn’t be able to do in the Production environment, risking the learning and data of the students.

With that in mind I have found certain things are critical to updating Blackboard correctly. When I say this I mean it is critical to follow a process because updating Blackboard or any other system can go sideways in a hurry and recovery is not always easy. Here are the extremely important items that I have come to do in a standard process:

  1. Reading the KB article for any update is very important. This includes clicking ALL the links and reading the whole thing. Set aside a period of a day or even two so that you can read, link, re-read and take notes on the KB article and its sublinks. I have to say that Blackboard is notorious in its completely long KB articles in regards to updates and patches. It would be nice to have shorter documentation, but you can’t fault detail if something goes wrong and you haven’t done your homework. Assume nothing, read everything.
  2. Have a Dev Site to test in. Add other people into this site such as instructional staff that have Staff privileges so that they can test how things work after an update. Remember, as a System Administrator you are charged with the technical side of keeping Blackboard running. Most likely you are not an educator or instructional staff member that uses Learn to teach with. So, having others that do teach that can test is invaluable. These same people can be placed in test courses to see how the student side functions too. While this bullet point is true a majority of the time, there are some SysAdmin’s that do know something about the instructional side. While that is good, it’s still not a best practice or wise to be your own tester. In fact, I have knowledge of how courses work, how grading works, Mashups, adding content, importing/exporting, etc. I don’t rely on myself as the sole person who tests the system after an update.
  3. Don’t update as soon as a patch comes out unless it is urgent and the affect of waiting is over weighed by the needs of the students and staff that are using Learn. I normally wait one to three months before applying a patch to the production site. I update the Dev site a month after the patch and test for 1 to 2 months before applying it to production.

I can’t say enough about the three items above. Read, Test, Be Patient. The last item is important in and of itself because rushing into a newly released patch is like being the first to update your smartphone or computer and brick it because the patch had an unknown side affect. If you do not have patience you will find that you have glitches every time. The actual process I follow when I am updating the production environment of Learn is most always the same, but can and sometimes does change depending on the results of the Dev site update.

  1. Find a time to do the update. We use Change Management to get approval to do the update before I actually do it. This gives the management team the opportunity to question me, ask about something they don’t understand and for us to see if everyone else in the school system doesn’t have a training planned when I have requested to do the update.
  2. Build Scotty time into your maintenance window. What’s Scotty time you are asking? If you have watched Star Trek, you know Scotty well and know that he always exaggerates how long something will take to fix. “Captain, it takes two hours to regenerate the dilithium crystals. I can’t do it in twenty minutes!” Guess what? He does it in 20 minutes. You need time to make sure that everything goes right and if it doesn’t you have the time to fix it. It also gives you the ability to relax, take your time, do it right, check your work before doing anything. Works great in my book and I don’t give myself too much time because then you will get questioned about why you got it done so quick when you thought it would take so long. Think it will take 2 hours to do correctly, give yourself 4. Think 8, ask for 12.
  3. Prepare at least two hours ahead of time to check your VM access, VPN access if needed and any other tools you will need. Don’t just check the day before because if it can go wrong it will.
  4. Have the KB article printed out at your side to look at. Highlight the process Blackboard says to do the update in Yellow.
  5. Print out the Best Practices to updating the B2’s. Follow this religiously, you won’t be disappointed.

Because the actual commands that you would run on a Dev site or a production site can vary based on update, patch or B2’s I am not going to place the actual commands that I do on my systems here. It is important to read and follow the best practices of the Blackboard KB articles that are associated with the patch or update you are doing and create the sequence from those articles.

I hope that this is helpful to someone in the future. The time it has taken me on the phone with Blackboard with an extremely good tier 2 engineer, in the Ask the MVP forum online and reading all possible articles on Blackboard have helped me create what you see above.