This version is a major update. All components need to be updated, from Dime.Scheduler to the connected plugins. This can be done using the Dime.Scheduler Installation Center that is provided in the package.
After having addressed the upgrade steps in this document, proceed with the general upgrade guide.
Customers who already have installed the Office 365-based Exchange connector should be cautious to upgrade the connector as there is a risk of data loss. Get in touch with our support to obtain the tools and procedures so you can safely upgrade to the bidirectional connector.
Beware that the bidirectional Dime.Scheduler Exchange connector can potentially put severe strain on the server when there are a lot of resources and/or many events that need to be linked back to Dime.Scheduler. It is therefore recommended to perform tests on the test environment and/or run a pilot with a few resources on the production instance of Dime.Scheduler. It's also best to increase the specs of the web server to accommodate the extra workload, if you intend to use the Exchange -> Dime.Scheduler synchronization mechanism.
Hosting multiple instances on the same machine
As MSMQ has been declared dead, we had to move on too. To communicate between Dime.Scheduler and connected plugins such as Microsoft Dynamics 365 Business Central and Microsoft Exchange, SQL Server will be used as the default medium. MSMQ in Dime.Scheduler is backwards compatible but from now on, SQL will be used as the default storage. Eventually MSMQ will be removed altogether while we continue the road to Dime.Scheduler as a Service ☁️. This switch makes it easier to horizontally scale Dime.Scheduler because no additional configuration is required.
☝️ This change is particularly important for customers who have installed multiple instances of Dime.Scheduler on the same machine. To keep plugin messages separated from other instances such user acceptance and test environments, you can configure the database in the installation center. This implies that if you want to run multiple instances of Dime.Scheduler on the same machine (which violates the best practices) but don't want to have shared database tables for messaging across the different instances, you'll also need to host a dedicated instance of the service bus and back office plugins. As shown below, this ensures total segregation between the different environments:
If you're not concerned about storing transactional plugin messages of a test environment on a production environment, then you can safely (or not so safely) ignore these warnings and use the environment variable to distinguish between the instances on the same server. The option to choose a dedicated messaging database is also a viable one.