VLE Guru

Originally posted on Feb 28, 2019. A quick post about our preprod upgrade to 2018 Q4 CU3. We experienced the same ORA-00001 error I reported in  Upgrading two dev environments to 2018 Q4   this time we tried running the installer again.  The row conflict PK1 it reports went up by 1.  Running the installer a third time it reached a vacant row and proceeded.  So next time we know to keep running the installer until it works (if only all workarounds were so simple). The upgrade went smooth.  We found that a few fixes we were applying were no longer necessary, specifically the XSS fix (the bb-file-filter-configuration.properties file is good on 2018 Q4), the Safari upload fix, the Xythos Cross Server Communication Fix, the Forum is enabled issue, and the JDK 1.8.0_151 and 1.8.0_152 Break Grade Center issue fixes were no longer required). The main new setting I had not realised we had to set was via the GUI: System Admin - Cloud Connector Sett...

Originally published on Feb 9, 2017. The VLE/LMS is such an important resource that for almost any institution downtime is unpopular. Despite this if you are self hosted or managed hosted downtime is inevitable in order to apply upgrades and take care of maintenance.  We negotiate our summer upgrade downtime in January.  We do this by identifying possible weekends between the end of semester 2 exams and the start of  our summer presessional teaching . Then we put those dates to deans for education and admin leaders in each faculty and ask them to vote on which weekend works best for them.  The option with the most votes is then chosen. Subsequently we announce this to users via a mailing list, and through other communications channels such as our  Institutional Portal , and social media such as  blogs ,  Facebook ,  twitter , the  student union  and so on. All communications point to central Upgrade 2017 page where we wi...

Posted to the community on Feb 6, 2017 Our Summer 2016 upgrade was successful, but running an upgrade project from start to finish in eight weeks had been a stressful experience.  We had only this short period of time due to local resourcing issues. To improve this going forwards I wrote a paper stating how upgrades would be controlled in the future. As we know, new versions of Blackboard Learn are released every other quarter.  Namely the  Q2  and  Q4  releases. Our upgrade window is always around late June.  A Q2 release in April is likely to be too short notice for us to upgrade to in June. Cumulative Updates (CU) are meant to be released every 1 to 2 months.  Experience shows that when a new version of Blackboard is released, a CU containing bug fixes is often released for previous versions at about the same time. Therefore the paper states that every June upgrade window we will upgrade to the Q4 release of the previou...

Originally posted to Blackboard Community site on Feb 6, 2017 In my previous post I wrote about how we set up a framework for performing Blackboard upgrades. Having set that up I could start planning the upgrade project. Risks The key risks I was able to identify with an upgrade to 9.1 Q4 2016 was that if we updated to the new responsive interface we would have to update  our fantastic Blackboard support website  with new screenshots.  Therefore the earlier we could get a test instance of Q4 the better. Making Plans So the project plan was to get a dev server upgraded as soon as possible, so that we could assess the impact of changes and document/configure as required.  I decided to plan to update one environment each month from January to March, and then in April hopefully in time for Q2 2017 a new Cumulative Update would be released for Q4 2016.  We could then implement the new CU across all environments and then freeze development to h...