Installation challenges with QATrack+ on Windows Server 2022 & Azure AD integration
Przemek
Hello QATrack+ community,
I'm currently attempting to set up QATrack+ on Windows Server 2022 with Python 3.9, following the official documentation at https://docs.qatrackplus.com/en/stable/install/win.html#new-installation . Despite carefully following the installation steps, I've encountered several persistent challenges that I'm hoping the community can help with.
Primary Issues:
1. Database migration failures when running `python manage.py migrate`
2. Dependency conflicts, particularly with numpy, matplotlib, and other scientific packages
3. The specific error I'm seeing is: "contourpy 1.2.1 requires numpy>=1.20, but you have numpy 1.19.5 which is incompatible"
I've tried multiple approaches, including:
- Using pip directly with the requirements files
- Setting up an Anaconda environment to better manage dependencies
- Downgrading specific packages to match the versions in the requirements
My ultimate goal is to implement Azure AD authentication using django-auth-adfs ( https://django-auth-adfs.readthedocs.io/en/latest/azure_ad_config_guide.html ) for our institution, but I need to get a stable QATrack+ installation working first.
Given the forum discussions about the project modernisation efforts and transition to newer Django/Python versions, I'm wondering:
1. Is anyone successfully running QATrack+ on Windows Server 2022 with newer Python versions?
2. Has anyone implemented Azure AD authentication with QATrack+?
3. Would it be better to wait for the modernisation efforts to complete before attempting this implementation?
4. Are there any specific workarounds for the dependency conflicts I'm experiencing?
I'd greatly appreciate any guidance, suggestions, or shared experiences from others who have navigated similar challenges.
Thank you,
Pshmey (Przemek)
OUH - Oxford University Hospital
Cody Crewson
Przemek
Hi Cody and QATrack+ Community,
First off, a huge thank you to Cody for your response and for sharing the requirements file - it made my life easier! I reused it with only minor tweaks (Django version and LDAP wheel adjustments) and managed to get QATrack+ running stably with LDAP on Windows Server 2022. I’ll detail my findings below to address your questions and hopefully help others in similar environments.
My Setup and Progress
After wrestling with the initial install, I’ve got QATrack+ running on Windows Server 2022 with Python 3.9 and traditional AD (LDAP) integration via django-auth-ldap. My ultimate goal was Azure AD authentication with django-auth-adfs, but as of April 2025, QATrack+ doesn’t support Azure AD natively due to dependency conflicts and the decommissioning of our ADFS servers. LDAP became the only viable option, and I’ve documented the process below.
Referring to Cody’s Points:
- Running
QATrack+ on Windows Server 2022 with Newer Python Versions:
I’ve successfully deployed QATrack+ on Windows Server 2022 with Python 3.9. LDAP is supported up to Python 3.12, but 3.9 is stable and tested (per the community and my experience). I stuck with 3.9 to match the qatrack31 environment from the docs. - Azure
AD Authentication with QATrack+:
Not yet—at this moment (April 2025), Azure AD integration isn’t working due to dependency mismatches with django-auth-adfs (requires Django 4.2+) and QATrack+’s reliance on Django 2.2.18. Also our ADFS servers are decommissioned, I pivoted to LDAP using django-auth-ldap. - Waiting
for Modernisation:
Given your timeline (stable Django 4.2 by summer 2025), for us, I needed a working system now, so I went with LDAP on Django 2.2.18. Hopefully modernisation might simplify Azure AD integration. - Workarounds
for Dependency Conflicts:
Yes I have traditional AD servers —see below for how I resolved the issues with numpy, django-auth-ldap, and other packages. Your requirements file helped here a lot!
Installation and Configuration Details
Initial Challenges
- Database Migration Failures: python manage.py migrate failed due to dependency conflicts.
- Dependency
Conflicts:
- QATrack+ requires Django 2.2.18.
- Latest django-auth-ldap (5.1.0) needs Django 4.2+, causing a version clash.
- contourpy 1.2.1 required numpy>=1.20, but QATrack+ bundled numpy 1.19.5.
Solutions
- Base
Installation:
Followed the official guide: QATrack+ Windows Installation.- Copied Deploy folder to C:\deploy\qatrackplus.
- Activated virtualenv: C:\deploy\venvs\qatrack31\Scripts\activate.
- Dependency
Fixes:
- Used Cody’s qatrack31_working_requirements.txt (thanks again!).
- Adjusted:
- Installed django-auth-ldap==2.3.0 (compatible with Django 2.2.18).
- python-ldap didn’t install cleanly via pip due to missing wheels, so I manually installed python_ldap-3.4.4-cp39-cp39-win_amd64.whl from package-index.level12.net.
- Updated numpy to 1.20.0 to satisfy contourpy.
- Run:
pip install -r qatrack31_working_requirements.txt
- Migration
Fix:
- Added from qatrack.qa.views import charts to C:\deploy\qatrackplus\qatrack\qa\urls.py near other imports (missing import caused migration errors).
- Run python manage.py migrate successfully after resolving dependencies.
- LDAP
Implementation:
- Created C:\deploy\qatrackplus\qatrack\myapp\backends.py to overcome authentication issues wrong grouping and permissions assignment:
from django_auth_ldap.backend import LDAPBackend, populate_user
from django.dispatch import receiver
import logging
logger = logging.getLogger('custom_ldap_backend')
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
handler.setFormatter(logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s'))
logger.addHandler(handler)
logger.propagate = False
class CustomLDAPBackend(LDAPBackend):
def authenticate(self, request, username=None, password=None, **kwargs):
logger.debug(f"Authenticating {username}")
user = super().authenticate(request, username=username, password=password, **kwargs)
if user: logger.debug(f"User {username} authenticated successfully via LDAP")
else: logger.debug(f"Authentication failed for {username}")
return user
@receiver(populate_user)
def assign_qatrack_groups(sender, user, ldap_user, **kwargs):
from qatrack.accounts.models import ActiveDirectoryGroupMap
logger.debug(f"Populating user {user.username}")
raw_groups = ldap_user.group_dns
ad_groups = [dn.split(',')[0].lower().replace('cn=', '') for dn in raw_groups]
group_map = {k.lower(): v for k, v in ActiveDirectoryGroupMap.group_map().items()}
for ad_group in ad_groups:
if ad_group in group_map:
logger.debug(f"Assigning groups for {ad_group}: {group_map[ad_group]}")
user.groups.add(*group_map[ad_group])
user.save()
- Updated C:\deploy\qatrackplus\qatrack\local_settings.py:
import ldap
from django_auth_ldap.config import LDAPSearch, ActiveDirectoryGroupType
import logging
AUTHENTICATION_BACKENDS = (
'myapp.backends.CustomLDAPBackend',
'qatrack.accounts.backends.QATrackAccountBackend',
'django.contrib.auth.backends.ModelBackend',
)
AUTH_LDAP_SERVER_URI = "ldaps://oxnet.nhs.uk:636"
AUTH_LDAP_BIND_DN = "used our Ad service account......"
AUTH_LDAP_BIND_PASSWORD = "its_password"
AUTH_LDAP_BASE_DN = "DC=oxnet,DC=nhs,DC=uk"
AUTH_LDAP_USER_SEARCH = LDAPSearch( correctly specified nested path, for other organisations can be different:
"OU=OXNET Managed Resources,DC=oxnet,DC=nhs,DC=uk",
ldap.SCOPE_SUBTREE,
"(sAMAccountName=%(user)s)"
)
AUTH_LDAP_USER_ATTR_MAP = {"first_name": "givenName", "last_name": "sn", "email": "mail"}
AUTH_LDAP_GROUP_TYPE = ActiveDirectoryGroupType()
AUTH_LDAP_GROUP_SEARCH = LDAPSearch( same for groups:
"OU=OXNET Managed Resources,DC=oxnet,DC=nhs,DC=uk",
ldap.SCOPE_SUBTREE,
"(objectClass=group)"
)
AUTH_LDAP_FIND_GROUP_PERMS = True
AUTH_LDAP_GROUP_CACHE_TIMEOUT = 21600
AUTH_LDAP_MIRROR_GROUPS = False
AUTH_LDAP_START_TLS = False
AUTH_LDAP_GLOBAL_OPTIONS = {
ldap.OPT_X_TLS_REQUIRE_CERT: ldap.OPT_X_TLS_NEVER,
ldap.OPT_REFERRALS: 0,
}
AUTH_LDAP_ALWAYS_UPDATE_USER = True
Additional Findings
- AppRegistryNotReady Error: Fixed by removing from myapp.backends import assign_qatrack_groups from local_settings.py—the signal in backends.py registers automatically via AUTHENTICATION_BACKENDS.
- Group Mapping: Configured in /admin/accounts/activedirectorygroupmap/ (QATrack+ was unable to assign user to groups and permissions form its interface before that change - every user logged don was defaulted to NON permissions and groups)
- SMTP: Port 25 failed; 587 works
- Logging: Added 'custom_ldap_backend' to settings.py LOGGING for debugging.
Cody, your advice to use your requirements file were key to getting this off the ground - as this was not working for me, vene when implementing ANACONDA VENV to resolve most of the issues - it was a matter "right version" - VS- "rights version" to most of the dependencies. The custom backends.py was necessary to map AD groups, as the default LDAP backend didn’t assign them without it—authentication worked, but group sync didn’t.
I hope this helps others in similar environments (Windows Server, traditional AD, Python 3.9).
I’ll keep notes on any further issues and share them for the KB. For now, LDAP works, emails send, and I’m setting up test lists. Looking forward to the Django 4.2 upgrade.
Thanks again,
Pshemy (Przemek)
OUH - Oxford University Hospital
Suman Badal
Przemek
- Windows 11 Compatibility: QATrack+ is officially supported on Windows Server (2016 or 2019) for production environments with multiple users, as it leverages server features like IIS for web hosting. However, for personal use on your laptop (Dell Vostro 15 3530, Windows 11 Pro), it will work fine. You can run it locally with CherryPy as the web server, no IIS needed if you're not sharing it widely. For single-device access (e.g., from one other computer), you can use your laptop’s IP address (like http://192.168.1.5:8000). Bute you will end up for some server-specific features a manual setup or installations on Windows 11.
- Windows Server Version: If you opt for a server, Windows Server 2022 Standard Edition is sufficient for QATrack+. It supports IIS, SQL Server, and basic virtualisation if needed. It work on all versions, but Standard is all you need for most setups.
- Laptop Configuration Support: Your laptop (i7 13th Gen, 16 GB RAM, 1 TB SSD) is great for running QATrack+ for one person or as a local server for a single device with no issues. As a server for multiple users, it’s good for small groups (5–10 users), but heavy use might slow it down or cause network hiccups.
- Future Compatibility: Your laptop’s specs are robust enough to handle QATrack+ now and likely any future updates, assuming requirements don’t drastically change. However, since QATrack+ is no longer actively maintained (per the developer’s announcement at https://groups.google.com/g/qatrack/c/79EoHF4U54Y ), updates are unlikely, so your setup should remain compatible.
- Known Bugs: The current QATrack+ version (e.g., v3.1.1.4) is stable and widely used in clinics globally. Some minor bugs may exist—check https://github.com/qatrackplus/qatrackplus/issues for details—but core functionality is reliable for now. Without active maintenance, future issues may go unaddressed.
- Installation: To install QATrack+ quickly, follow the official Windows guide: https://docs.qatrackplus.com/en/stable/install/win.html . It covers installing Python, Git, a database, and CherryPy. For personal use (solo use), you can skip IIS and run CherryPy locally. Coordinate with your IT team to ensure dependencies are installed, and you should be up and running soon.
- Windows 11 vs. Server: Windows 11 is compatible for your use case (solo or single-device access) and doesn’t require a server OS. You’d only need to set up CherryPy as a service for background operation—no IIS unless you want a web-facing URL. If you later need multi-user access, consider a server OS for easier scaling.
- Database Compatibility: Your SQL Server 2014 (SSMS 12.0.4100.1) is compatible with QATrack+, as is your TrueBeam v2.0 setup on Windows Server 2012 R2. You can also use SQLite for simplicity or PostgreSQL for robustness. See https://docs.qatrackplus.com/en/stable/install/install.html#database for options.
Pshemy (Przemek)
OUH - Oxford University Hospital