Technical Articles

Business Integrations Assists Winter Webinar Series

Thu, 24 Mar 2022 11:37:00 GMT

This winter has been a busy one for webinars. This is a great time of year to offer webinars as it is cold and dark outside and spending an hour or two immersed in a fascinating subject is time well spent.

We have helped The Showing Council with their first foray into webinars, helping produce their Winter Webinar Series. The Showing Council’s aim was to provide a platform for education and discussion on showing matters for their member bodies. The Showing Council opened the final webinar to non-members and was on the topic “will we be riding in 20 years-time?”. Social License to Operate is a hot topic in the horse world now, and this was a fascinating presentation by Dr Jane Nixon MRCVS. Following the presentation there was a moderated question-and-answer session with several leading industry figures.

This final webinar was sponsored by SEIB and you can find out more information on the speakers and panellists here.

OrchardCMS - Essential site modules

Mon, 09 Apr 2018 11:04:00 GMT

Site Essentials

This article was originally published directly on Github, I've added a small precis here in order to link through to it.

We design and build web sites for clients using OrchardCMS which, out-of-the-box, doesn't come with some of the core functionality you'd generally expect from a CMS: Sitemaps, FavIcons, SEO etc etc.

Although there appear to be a lot of modules available for Orchard in the gallery, many are out of date, or don't work with the latest version (1.10.2), or are generally no longer supported.
However, rather than starting from scratch, we took a bunch of those third-party modules and reworked them where necessary. We currently use these modules in production websites, and we generally refer to them as our 'Site Essentials' - as they contain functionality we'd generally use in every website.

Modules

All of these modules have been forked and are available on our main Github organisation page. The main article about the modules, the changes we've made and our coding approach are detailed here.

Yaplex.SEO
- Robots.txt - Enables an admin interface to manage the contents of the robots file.
- SEO Metadata - Enables configuration of SEO keywords and metadata for each content item .
Vandelay.Industries
- Favicon - Reworked to enable support for multiple favicons
Mod.CookieConsent
- Cookie Consent - Enables site to be compliant with cookie legislation
Om.Orchard.SocialMetaTags
- OpenGraph tags - Provides ability to configure opengraph settings per content item.
WebAdvanced.Sitemap
- Site Map - Provides configurable xml and html sitemaps
Lombiq.SimpleAnalytics
- Analytics - Configures settings for Google Analytics etc.
Devworx.CodePrettify
- Code Prettification - Enables code in an article to be tagged and formatted nicely.

Orchard Multi-Tenancy: Part 1 - Schemas are your friend

Fri, 08 Dec 2017 17:49:00 GMT

Orchard CMS includes a very simple but powerful module that allows you to host any number of independent tenant websites using a single Orchard installation and IIS site. The sites are independent in that they all require their own set of orchard database tables, albeit they share an appdomain. Instructions for setting up multi-tenancy are provided by Orchard here.

Two of the options required for setting up the tenant site are a database connection-string and a table prefix. A prefix isn't needed if each tenant is going to have their own database. If tenant sites are going to share a database then one option (we'll come to another option later) is to use a prefix - this will prepend all table names with the supplied prefix. Even modules installed later on that create their own tables will also have prefixed tables - as long as they follow the Orchard/NHibernate approach for building tables. Note that there isn't an option to use a single set of tables to manage all tenants - as there is with Kentico for example, where all tables are keyed on a SiteID column.

Separate Databases

The benefits of having a separate database for each tenant include the flexibility around being able to manage security, performance and backup/restore operations etc in splendid isolation - you can move the database from one storage location to another, or even different servers without impacting any other tenant site for example. However, such flexibility and isolation comes at a price - and that is manageability: now you might have separate scripts and jobs to manage backups/alerts/monitoring etc. You might also not have the luxury of using multiple databases with your hosting provider.

Shared Database

However, given that you've decided on a multi-tenancy option to begin with and sites will already share a web server and appdomain, you're probably OK with sites sharing a database too. Seemingly then you're stuck with table prefixes.

This option definitely works, and I haven't come across any technical issues per se that would preclude using prefixes - other than the potential usage of a non-Orchard third-party module/application that doesn't allow for prefixed table names etc.

However, this model does compromise security somewhat. In a single-database single-schema scenario, managing different database users so that they have different object-level permissions and can only view/manage tables that they created, all in the same schema, is probably nigh-on impossible/unworkable. And whilst you might consider the risk low, there would be nothing preventing a malicious/badly-written/badly-designed piece of code from stealing/trashing data for all the tenants in your instance.

Having prefixed tables also means that you can't simply run the same sql script for each tenant; you have to copy/paste and replace prefixes - or write some clever SP to take care of it for you.

Shared Database - Multiple schemas

The easiest solution we've found to managing the single-database scenario for Orchard multi-tenancy is to use a separate database schema for each site, with a separate login and user to match and then grant a role to each user to govern permissions. This only applies to Sql Server - Sql Compact doesn't support schemas.

We initially created a role with these basic permissions and execute it once on each new database we create:

/* Create the Role */
USE [Orchard_DevDB]
CREATE ROLE [Orchard_Site_Role] AUTHORIZATION [dbo]
GO
/* Add the permissions */
GRANT CREATE TABLE TO [Orchard_Site_Role]
GRANT CREATE FUNCTION TO [Orchard_Site_Role]
GRANT CREATE PROCEDURE TO [Orchard_Site_Role]
GRANT CREATE TYPE TO [Orchard_Site_Role]
GRANT CREATE VIEW TO [Orchard_Site_Role]
GO

And then for each new tenant we are about to create, we run a version of this script to create a new schema, login and user specifically for that tenant:

USE [master]
CREATE LOGIN [Orchard_DevDB_TestUserA] WITH PASSWORD=N'#####', DEFAULT_DATABASE=[Orchard_DevDB], CHECK_EXPIRATION=OFF, CHECK_POLICY=ON
GO
USE [Orchard_DevDB]
CREATE USER [TestUserA] FOR LOGIN [Orchard_DevDB_TestUserA] WITH DEFAULT_SCHEMA=[TestUserA]
ALTER ROLE [Orchard_Site_Role] ADD MEMBER [TestUserA]
CREATE SCHEMA [TestUserA] AUTHORIZATION TestUserA]
GO

Notice that we use the same name for the schema and user as they will be unique in each database, but prefix the login with the database name to make them unique on each server.

Once this tenant-specific script has been executed, go ahead and create the tenant from the host admin site, without the need for a table prefix and specifying the connection-string i.e.

Data Source=<DbServer>;Initial Catalog=Orchard_DevDB;Persist Security Info=True;User ID=TestUserA;Password=#####

Now you can reuse sql scripts across tenants if necessary and although this hasn't helped with backup/restore isolation directly, at least we now have a 'contained' set of database objects that can be managed with a single login. This login won't have permission to alter database objects for any other tenants, helping to safeguard your tenants' data.

As always, the decisions on how to split up sites and their databases will depend on the time/money/resources at your disposal to set things up and maintain them. Hopefully this article provides a useful compromise between full isolation and full shared access.

Migrating a workgroup-based TFS installation to Visual Studio Team Services

Thu, 14 Sep 2017 12:03:00 GMT

Overview

Earlier this year we decided to migrate our source control from an in-house Team Foundation Server 2015 installation running on Windows Server 2012R2 to Visual Studio Team Services. One of the key benefits for us was reducing the overhead of managing the TFS server itself (e.g. Windows updates, TFS updates, SQL Server updates, SQL backups, machine backups) as well as ensuring we can easily get to our code from anywhere and also having the ability to integrate various aspects of Office 365 and Team Services using Microsoft Flow.

Migration Process

The overall process to migrate from TFS to VSTS is a little involved, but basically requires you to package up the TFS collection database alongside some configuration files, upload them to Azure and kick off the import process. Microsoft provides this general migration overview, which links to this migration guide.

The migration guide assumes that you are migrating from an Active Directory environment and that you have an Azure Active Directory tenant already setup - we had the latter as we had an Office 365 subscription, but not the former. Our TFS installation was built in a workgroup environment - our local infrastructure had grown somewhat organically and we'd never used Active Directory as it seemed overkill for our limited number of users and servers.

One of the steps in the migration process is to generate a number of configuraton files including an Identity Mapping file, by running the TfsMigrator prepare command. This is the key step, without having an AD environment this mapping file does not correlate local windows users to valid users in the AAD.

When we ran the TFSMigrator command originally, without doing any of the steps below, it generated an IdentityMap.csv file that contained lines like these:

TFS012\winuser01,S-1-5-21-1519684228-4057255379-2957299516-4015,,Basic,,NO MATCH,2017-06-20T14:46:50Z

The key text here is the 'NO MATCH' - which means the tool couldn't map a local windows account to an Azure AD user, it needs to be able to do that if you want to migrate the ownership/assignment of work items. Without a match the import would still work, but the migrated work items would refer to 'ghost' users. We wanted to ensure we had some continuity and that our Office365/AAD users could seamlessley manage work items created by the original local windows users as if they were their own.

General Approach

So, our challenge was to convert our single-server TFS installation from a workgroup-based one to an AD environment. The approach taken was to:

Create a new VM running as an AD controller.
Configure the AD and add users.
Add the TFS machine to the domain.
Map the TFS users to domain users.
Proceed with the TFS migration commands.

I'm not going to go through all of the steps in the TFS migration itself, as the guides cover most of the setup and the details really will vary based on how large your company is, the complexity of your TFS infrastructure and configuration etc. I shall however recommend a few things you should do when performing a TFS Migration (whether you perform the steps below or not):

Backup your servers and databases. Clearly do this before proceeding with the migration, but also before/after key steps in the process.
If using VMs then checkpoint them! Do this frequently so you can revert and try again if something hasn't gone to plan.
Take notes and be methodical. Document every step you make, every server configuration change, every command you execute.

Detailed Steps:

So, without any further ado here are the steps we undertook to convert a workgroup-based TFS 2015 installation to a domain-based TFS 2017 installation:

Upgrade TFS to the latest version as per the migration documentation (TFS2017 in our case).
Create a new VM and install Windows Server 2016 Standard edition.
Configure the new server with a static IP and perform any windows updates.
The simplest way to create an AD Controller is to install the 'Windows Server Essentials Experience' role using the server manager to Add Roles/Features:
Once that has installed you'll see a notification that this role need configuring:
Enter the company details and the Full DNS Name - use the primary domain that is associated with your Azure AD:
Using Server Manager -> Tools, Create all of the AD users necessary that are referenced in TFS, making sure that you mirror your AAD users exactly: (You might also want to create a test user for the purposes of validating connections to the AD)
Ensure that the users' Account details are correct and replicate exactly the user information in the Azure AAD:
The TFS migration guide recommends using the AD Connect tool to synchronize users - and this certainly seemd to be required in order to ensure that the users were mapped correctly. The guide for installing and configuring this is here. For the initial install perform a custom setup and leave all the options empty:
Once that has completed the AD Connect wizard will continue and we want to make sure that just a basic synchronization is setup. For the 'User Sign-In' page, select 'Do not configure'. Next, supply global administrator credentials for the Azure AD. Once they have been verirfied you'll get to specify the directory to connect - there should be just the one so add that in:
The next step is the crucial one that will help us ensure we have matching users - make sure this is set as 'userPrincipalName'.
The remaining steps can all be left as default settings and then allow the synchronization to commence once you're happy with the configuration. To check this has run successfully, you can:
1. View details of the AD Connect synchronization in the Azure portal
2. Use the Synchronization Service tool on the AD server - although this hasn't been written with any expectation of a pleasant user experience...
Back to TFS, now we need to add this server to a domain. Log in to the TFS server using a normal administrator account and browse to the AD server: http://<ADservername>/Connect
Follow the instructions and then to validate, log off, then log back in with your test AD user that you created earlier.
Map TFS users to domain users.
On your TFS machine, navigate to to the TFS tools directory (e.g. C:\Program Files\Microsoft Team Foundation Server 15.0\Tools)
We'll be using the TFSConfig command in this format to map users from their original local windows accounts to their new AD accounts:
TFSConfig identities /change /fromdomain:<TFShostname> /todomain:<mycompany.com> /account:<oldaccountname> /toaccount:<newaccountname>

For example:
TFSConfig identities /change /fromdomain:TFS2012 /todomain:mycompany.com /account:winuser01 /toaccount:andy.mason

Repeat this step for each local windows user that is referenced in TFS and that needs to be mapped to an AD user and hence to an AAD user.
Assuming by now you have been following the TFS Migration guide and have downloaded the latest TFS Migration tools, run a prepare command in order to generate an IdentityMap.csv file e.g.:

TfsMigrator prepare /collection:https://<TFShostname>/DefaultCollection /tenantDomainName:<mycompany.com>
Hopefully now your IdentityMap.csv file contains entries like these that map from the on-premises domain users to AAD users:

mycompany.com\andy.mason,S-1-5-21-2038798617-1478562495-3409822930-1126,andy.mason@mycompany.com,Basic,,OK,2017-06-20T14:46:50Z
At this point, log in to the azure portal and turn off the AD Connect synchronization as well as disabling it on the AD server.

Microsoft allow you to perform 2 TFS migrations by default - a dry run and a production run. Once you've completed your production run and everything is working smoothly and has been checked, double-checked and triple-checked then you can pension off the AD VM and your TFS machine(s).

The steps listed above have only been tested on a single-server TFS installation, where SQL Server was installed on the same machine and there was no Sharepoint instance. Only the TFS machine was added to the local AD and no other machines on the network were affected.

Also, the intent here was to throw away the AD and TFS machines post-migration. In some cases it might be preferable to perform a company-wide migration to an AD environment anyway, which was permanently synchronized with the Azure AD. In which case, clearly the AD Connect setup would be different.