Gallery Server Your media. Your website. Easy. Mon, 10 Dec 2018 01:04:17 +0000 en-US hourly 1 Gallery Server transitioning to 100% free open source model Mon, 10 Dec 2018 01:04:17 +0000 A brief history of Gallery Server

Gallery Server began in 2003 when I took a few months off of work to travel the United States with my new bride. I wanted to share photos of our trip so I thought I would throw something together with the newly released .NET Framework and enhance my programming skills at the same time. I was really happy with how it turned out, so I released it as a 100% free, open source product in 2005. It wasn’t long before I added a donate button on the website and started getting donations. For several years, I sent a free Dilbert book to anyone who donated $50 or more.

This donation model brought in around $500 – $1000 a month. It was really satisfying to give the product away and let folks pay whatever amount they valued the software. But $1000 a month is essentially minimum wage and this was my main source of income, so I was constantly brainstorming ways to increase revenue. With reluctance I eventually added a commercial edition, which later morphed into three editions: Home & Nonprofit, Enterprise, and Enterprise Ultimate. My goal was to build a sustainable business model that was also rewarding on a personal level. It has always been important to me to have a free edition with as many features as possible while trying to get enough revenue to pay the bills.

I’ve been working on Gallery Server nearly full time for the last 15 years. Unfortunately, I never got the revenue to where it needed to be. Every single year I could have made more money being a developer for some corporation. But that was okay because I valued work satisfaction more than money, and Gallery Server has truly been a labor of love. It is a solid software product with an architecture that follows industry standard best practices, and reports of bugs have dwindled to near zero.

A new beginning

However, I’m at a point in my life where my expenses are exceeding revenue, and my hand is forced. I must work in the private sector and, as such, do not have time to continue working on Gallery Server. As of today, I have stopped selling all commercial editions of Gallery Server.

I moved the source code to GitHub, removed all licensing restrictions, and posted compiled versions for installation and upgrade as a new 4.5.0 release. There is now a single edition called Gallery Server.

The good news

All the features of Gallery Server Enterprise are included in this release. That means users of the Free and Home & Nonprofit editions can immediately upgrade to 4.5.0 at no cost, and enjoy access to the enterprise features you may have wanted but couldn’t afford. Upgrading any 4.x edition to the new, open source 4.5.0 release is just as simple as previous upgrades. Download the upgrade zip file from GitHub and extract the contents over your existing files. I updated the Admin Guide, so refer to that for more details. It’s a download on the GitHub release page.

By providing the source code, I have given you the power to enhance it, fix bugs, or modify it as you see fit. If you aren’t a developer, you can hire a .NET consultant to make the changes for you. The code is 100% C#, ASP.NET, and JavaScript. I am proud to say it has the best documentation and architecture of any software app I have encountered in my career.

The bad news

Significant development on Gallery Server has stopped. If you submit a GitHub issue, I don’t know if I’m going to have the bandwidth to address it. I will do what I can to help. If you report an issue and the fix is easy, I’ll take care of it. If you submit a pull request and it’s decent quality, I may merge it. With any luck, some developers will jump into the GitHub project and help keep it active. Maybe it’s you?

What about existing customers?

Your existing Gallery Server installation will continue to work. You can continue deactivating and activating your previously purchased license. At some point in the future, the endpoint for the activation will be taken down. When this happens, Gallery Server has a built-in fail safe mode that automatically considers the license activated when it cannot reach the licensing server. That means you can continue using and installing any version of Gallery Server you already own, even when the website no longer exists. Even so, I anticipate the website to be up for at least another year. The forum is a valuable source of knowledge and the website provides valuable information about features.

If you bought or renewed your Gallery Server subscription within the past year, you are entitled to one year of free support. I intend to honor that agreement and continue providing support until your renewal date is up. My day job means I may not be able to answer until the evenings and weekends, but I won’t leave you hanging.

In the coming days I will be updating each active subscription to the ‘pending cancellation’ status. That will give you continued access to downloads on the website, but you will not be auto-charged on your renewal date.

Final thoughts

I still dream about all the fun things I’d like to do with Gallery Server. What a treat it would be if I could rewrite the front end in Angular and the back end in .NET Core! But for the foreseeable future there just isn’t enough time. I need to focus on being a good dad and provider for my family.

I thank every one of you who have supported me over the years, especially if you made a donation in those early years. My customers – you – have always been fantastic to work with and it’s been a pleasure talking with you on the phone or in the forum as I installed your gallery or helped with some issue.

I’ll see you on the interweb.

]]> 2
4.4.3 Released Wed, 04 Jul 2018 22:33:08 +0000 Today we released 4.4.3. It’s a minor update, containing a few bug fixes and no new features. Applying it to your 4.X installation is easy — just copy the files from the upgrade package over your existing installation. There are no web.config changes to merge and you don’t have to worry about the version_key.txt file or your license information. Get the upgrade package from your downloads page. If you are upgrading from an earlier version, follow the instructions in the Admin Guide.

These are the bugs that are fixed. More details are available on the release history page.

  • Error “Value does not fall within the expected range” when adding image
  • Cannot assign an album owner when the user name contains an ampersand
  • Error when unassigning user as an album owner
  • PrincipalServerDownException when using the AD group provider
]]> 0
4.4.2 dramatically improves performance in multi-gallery scenarios Wed, 07 Feb 2018 23:21:20 +0000 Today we are releasing Gallery Server 4.4.2. As with the 4.4.1 release, we continue to focus on performance. Upgrading from 4.X is as easy as copying the files from the upgrade package over your existing files.

Performance gains

One of our customers, Reto Ambühler in Switzerland, was experiencing large wait times for several common editing scenarios, such as adding an album and creating a role. There was also a significant startup time for the gallery. He generously shared his database with us. It contained 64 galleries, 1403 albums, and 53,000 media assets.

We were able to reproduce his performance issues. For example, browsing to a new album took 55 seconds, deleting an album took 38 seconds, and deleting 10 empty albums took a staggering 6 minutes and 22 seconds!

Most customers do not experience such poor performance, even with several times more media assets. His scenario was unique because he had a large number of galleries, which amplified the amount of data that was loaded after any edits that purged the cache. We want Gallery Server to handle this scenario, so we went to work with our performance tools to see what we could find.

We found several places where we could make simple changes that dramatically improved performance. For example, when adding a role on the manage roles page, Gallery Server displays an album tree containing the gallery node and one level of child albums. In Reto’s case, that meant displaying 64 galleries and the first level of child albums in each, resulting in a dialog that displayed hundreds of albums. By changing this to show only the root gallery nodes, we reduced the time it took to display the add new role dialog from 95 seconds to 7.5 seconds, a 92% improvement. This had the added benefit of being much more usable as well.

Another area that had a dramatic impact on performance was some validation code that ran each time the gallery cache was purged, which occurred during many common tasks such as adding and deleting albums. This validation code looks for missing rows in the database and automatically inserts them. For example, if one of the gallery settings for a particular gallery is missing, this routine restores it by making a copy of the matching setting associated with the template gallery.

But in practice, the validation routine rarely fixes anything because the primary scenario where a row might be missing is when an administrator manually goes into the database and starts deleting records. And that should rarely, if ever, occur. However, we didn’t want to remove the validation altogether, because we couldn’t be sure how often it actually was being useful and possibly saving users a headache and us a support call. So we altered when it ran to once per application lifecycle. And we run it on a background thread so it doesn’t impact page load times.

This change, combined with a few others, helped reduce the time it took to delete ten empty albums from 6 minutes 22 seconds down to 2.5 seconds, an incredible 99.4% improvement!

The table below compares times for the same tasks conducted in 4.4.1 and 4.4.2. Notice they are at least 80% faster. While most of you will not see the same level of performance gains, especially if you have a single gallery in your installation, you may still noticed a snappier gallery.

Large, multi-gallery installation

64 galleries, 1403 albums, and 53,000 media assets

Task 4.4.1
 Startup 53 4 93%
 Navigate to album after creation 38 <1 97%
 Navigate to album after sync 38 <1 97%
 Delete one album 38 <1 97%
 Delete ten albums 382 2.5 99%
 Add new role (w/ empty cache) 95 7.5 92%
 Edit role (w/ empty cache) 91 7 92%
 Save gallery setting 5 1 80%
 Activate move/copy dialog 119 8 93%
 Move/copy empty album 54 <1 98%


Bug fixes

Role/album relationships may disappear in multi-gallery scenarios – We thought we fixed this in 4.4.1, but apparently not. It’s been tough because we’ve never been able to reproduce it. In this version, we moved the role validation routine to run just once per application lifecycle (like we did with the other validation code) and we rewrote how it did the validation. We hope we finally nailed it.

Cannot upload a watermark image – We didn’t notice a breaking change when we updated to the latest version of the plupload widget back in 4.3.0. The new version changed a JavaScript namespace, preventing users from uploading a new watermark image on the Image Settings page. This has now been fixed.

A complete list of bug fixes and details about each one can be found in the 4.4.1 Fixed Defect Report.

How to apply this update

If your existing gallery is 4.X, upgrading is easy — just copy the files from the upgrade package over your existing installation. There are no web.config changes to merge and you don’t have to worry about the version_key.txt file or your license information. Get the upgrade package from your downloads page. If you are upgrading from an earlier version, follow the instructions in the Admin Guide.

]]> 0
4.4.1 improves performance and fixes important bugs Fri, 05 Jan 2018 21:31:24 +0000 Today we are releasing Gallery Server 4.4.1. While it includes no new features, it improves performance in several key areas and fixes a few important bugs. We recommend migrating to it immediately, especially since upgrading from 4.X is as easy as copying the files from the upgrade package over your existing files.

Performance gains

We spent a lot of time profiling Gallery Server, looking for performance bottlenecks in various configurations, from small galleries using SQL CE to large, multiple gallery environments with 1,000,000 assets. We found several opportunities were we could more narrowly purge the cache after certain changes, thereby preventing Gallery Server from having to reload data that didn’t actually change.

Gallery Server uses an in-memory cache to store a list of galleries and all the album IDs in each. This is expensive to rebuild, especially because reloading it causes a validation routine to run that ensure the integrity of several database tables.

Beginning in 4.4.1, the gallery cache is no longer cleared when assigning an album thumbnail, syncing an album if there are no changes to the album, uploading files to an album, and a few other cases. The speed improvement will be most dramatic in very large, multiple gallery installations.

We also identified areas where we were persisting data structures to the database when nothing had actually changed. By more accurately identifying changed data, we reduced the number of times we had to call the database. This improvement is most noticeable when using SQL CE, since it is a rather slow database engine compared to SQL Server.

Bug fixes

We were finally able to track down the root cause of a nasty bug we’ve been trying to fix for some time. We did it with significant help from one of our customers, Reto Ambühler in Switzerland. Reto has a large, multiple gallery database that was frequently exhibiting the issues that had only rarely been reported from others, and never been reproducible. Reto shared the database with us and we were finally able to reproduce the behavior. Thank you Reto, for your time and patience.

It boiled down to a faulty lock mechanism when reloading the gallery cache from the database. The issue only appeared when multiple galleries were used and in certain multi-threaded scenarios. Depending on how users were interacting with the gallery, they saw a variety of failures, but they all had this same cause.

  • A page may be randomly assigned to another gallery
  • User may receive error “Invalid state of GalleryServerRole instance”
  • Role/album relationships may disappear

We fixed the lock mechanism and are confident we’ve finally seen the last of these errors.

Safer file moves – Just before releasing 4.4.1, a customer reported getting the error “cannot create a file when that file already exists” when rotating an image. After investigating and consulting StackOverflow, we learned that antivirus software and certain scenarios with multiple threads could cause an issue when replacing an existing file. So we reworked the move file routine to include retry logic up to 10 times with a 500 ms delay between attempts. We also save a backup of the original file and restore it if the move ultimately fails.

False error messages – When an image is edited, Gallery Server often has to create a new image, copy the metadata properties, delete the original, and finally move the newly created image into the same place as the original. We noticed that the metadata copy routine would falsely generate the error “This codec does not support the specified property” when an image did not have any tags (keywords) or the date picture taken property. This error was hidden from the user, but it was logged in the event log and an email was sent to administrators. We updated the routine to avoid this error.

A side benefit to fixing this is that by not logging the false errors, editing performance improves. In one of our tests involving rotating fifty 100 KB images, the elapsed time dropped from 1 minutes 28 seconds to 5 seconds.

A complete list of bug fixes and details about each one can be found in the 4.4.1 Fixed Defect Report.

How to apply this update

If your existing gallery is 4.X, upgrading is easy — just copy the files from the upgrade package over your existing installation. There are no web.config changes to merge and you don’t have to worry about the version_key.txt file or your license information. Get the upgrade package from your downloads page. If you are upgrading from an earlier version, follow the instructions in the Admin Guide.

]]> 0
Just Released: 4.4 gets updated HTML editor and other goodies Mon, 28 Aug 2017 21:19:51 +0000 Gallery Server 4.4 is now out of development and in your hands. We updated the tinyMCE HTML editor to the latest version, taking it from 4.5.3 to 4.6.5. This tinyMCE update includes dozens of bug fixes and several new features. A complete list can be seen here:

New feature: Share asset URL

We updated the share dialog to include a link directly to the media asset file:

This URL is a direct link to your JPG, video, etc. This differs from the page URL, which is a link to the web page containing the media asset. Use the asset URL any time you want to refer to the media asset without the chrome and distraction of the Gallery Server web page.

The URL will point to the version of the asset that is currently active in the View ribbon tab. That is, when optimized is selected, the URL will point to the web-optimized version of the asset. When original is selected, the URL points to the original media file.

The great thing about this link is that it enforces the existing security rules for the asset, protecting your assets even if the link gets into the wrong hands. In those cases where you want to share a protected asset with someone who does not have access to the gallery, we recommend you copy the asset to a public album and share the link from there.

How to apply this update

If your existing gallery is 4.X, upgrading is easy — just copy the files from the upgrade package over your existing installation. There are no web.config changes to merge and you don’t have to worry about the version_key.txt file or your license information. Get the upgrade package from your downloads page. If you are upgrading from an earlier version, follow the instructions in the Admin Guide.

Bug fixes

Gallery Server has become very stable in the last few releases, and there just aren’t many bugs to fix. This release has just four.

  • Cannot delete orphan album from User Settings page
  • Event logger may contain password
  • Gallery Server may alter XML in user description
  • Error “Invalid state of GalleryServerRole instance” may occur

Additional details about these bug fixes can be found here.

]]> 0
Gallery Server Binary Pack Updated Wed, 12 Apr 2017 15:40:45 +0000 Today we released an updated version of the Gallery Server Binary Pack. It contains the latest versions of three open source utilities that give you advanced gallery functionality such as audio/video transcoding and video, CR2, NEF, PDF, TIF and EPS image generation. They are ImageMagick 7.0.5, FFmpeg 3.2.4, and GhostScript 9.21.

Before installing these utilities, first uninstall any existing installations of ImageMagick and GhostScript on your web server.

Then download the Binary Pack and extract the contents of the zip file to an empty directory. Copy ffmpeg.exe to the bin directory of your Gallery Server web application. Install GhostScript by copying gs921w64.exe to your web server and then running it. If you are using a web hosting company, you likely aren’t allowed to run executables on the server. In this case, the best you can do is create a support ticket to ask them to do it.

Install ImageMagick by copying ImageMagick-7.0.5-4-Q16-x64-dll.exe to your web server and then running it. **IMPORTANT** During the setup be sure to select this option: Install legacy utilities (e.g. convert). If you leave this unchecked ImageMagick will not include convert.exe, which is required by Gallery Server. This is caused by a change in ImageMagick 7.X, which switched from convert.exe to magick.exe. Future versions of Gallery Server will likely be updated to account for this change, but for now you must select the option to install legacy utilities. If you can’t run the ImageMagick installer because you are using a hosting company, a pretty good alternative is to copy convert.exe to the bin directory of your Gallery Server web application. This will give you most, but not all, of the benefits of ImageMagick.

Finally, go to the Site Settings page in Gallery Server and update the path to ImageMagick. If you installed the full 7.0.5 version, the path will be C:\Program Files\ImageMagick-7.0.5-Q16.


]]> 0
Just Released: 4.3 adds support for replacing existing media files Fri, 10 Feb 2017 21:31:29 +0000 Yesterday we released Gallery Server 4.3. You can now replace the file of an existing media asset without losing any metadata or changing its ID. There is also an improved algorithm for generating resized client-side images. And, as always, there are bug fixes.

How to apply this update

If your existing gallery is 4.X, upgrading is easy — just copy the files from the upgrade package over your existing installation. There are no web.config changes to merge and you don’t have to worry about the version_key.txt file or your license information. Get the upgrade package from your downloads page. If you are upgrading from an earlier version, follow the instructions in the Admin Guide.

Replace existing media asset

This has been a top feature request and we are glad to finally implement it. It is available in all editions, including Gallery Server Free. Beginning with 4.3.0, a new replace button appears in the ribbon toolbar:


Clicking the button brings up a small window where you can select a replacement file:


After you select a replacement file, click the Upload & Replace button to send it to the server, where it will replace your original media asset file.

This is great for those situations where you need to update the file associated with a media asset. For example, you may be editing an image in Photoshop, updating a document, or trimming a video. In each of these cases, you can download the file, make your change, and then use the replace function to push it back to the server. The ID remains the same, and most of the asset’s properties are unchanged.

Which properties change? Well, they’re the ones you would expect, as they are properties of the file and it makes sense to refresh them. They are width, height, dimensions, orientation, file name, file size, audio format, video format, bitrate, and duration. That is, Gallery Server recalculates these metadata from the uploaded file and updates the corresponding properties of the asset in your gallery.

What about other properties, especially those that tend to be embedded in images such as date picture taken, shutter speed, and camera model? It was a challenge for us to figure out the best approach here, because we can think of pros and cons to the different options. If Gallery Server re-extracts all metadata from an image when it is replaced, you may lose valuable data in those cases where your image editor stripped out meta properties when you saved it. If it doesn’t re-extract, you won’t get meta updates you’ve made with an external tagging or metadata writing program. There wasn’t a single approach guaranteed to be what you want in all cases. In the end, Gallery Server recalculates the file-based meta properties and leaves the rest alone. We think this is the right balance that will work for most users.

If you want Gallery Server to re-extract all the meta properties, delete the original media asset and then upload the replacement file. Gallery Server treats this as a new media asset, so it will have a new ID. Any external links that pointed to your old media asset will not automatically link to the new asset, so keep that in mind.

Which properties get pushed into the replacement file?

We talked about how Gallery Server updates the properties of the media asset. But it can also write properties to the original JPG image file. During file replacement, does Gallery Server push the current properties of the media asset to the internal metadata of the replacement file? It depends on whether you’ve enabled metadata writing on the Metadata page in the site admin area.

In the above screenshot, the tags property is writable and the title and caption properties are not. Let’s say you have an image media asset and you’ve entered values for all three of these properties. Then you use the new replace function to swap the file with another image. Gallery Server will push the tags into the replacement file but not the title or caption. All three properties continue to appear in the gallery just as before.

Higher quality client-side image resizing

We kind of cheated with this one, since we didn’t write it. It’s a new feature of the upload widget plUpload. It uses an improved algorithm to generate resized client-side images. This comes into play when you upload images on the Add media page:

When you select the option to discard the original file, Gallery Server, through the upload widget, generates a web-optimized image on the client and uploads that to the server. The biggest benefit to this is faster uploading, since the resized images are often dramatically smaller than the original. The new algorithm uses bilinear resampling to create a high quality image. Nice!

Bug fixes

Gallery Server has become very stable in the last few releases, and there just aren’t many bugs to fix. This release has just two. Read more about them here.

  • User with EditMediaObject permission may get permission error when using the image editor
  • Thumbnail image may have incorrect width and height after rotation
]]> 0
Another happy Gallery Server customer Tue, 10 Jan 2017 17:12:04 +0000 We love it when customers take the time to give us feedback, regardless of whether it’s positive or negative. Today I thought I’d share a compliment we received yesterday from Tom Slaughter at Earth Oasis Computers.

The ability to edit the original file metadata is AWESOME. I’ve been playing with it and am so happy I upgraded!!

Thanks, Tom!

]]> 0
4.2.1 Released Thu, 08 Dec 2016 23:30:56 +0000 Yesterday we released 4.2.1. It’s a minor update to 4.2.0, containing a few bug fixes and no new features. Applying it to your 4.X installation is easy — just copy the files from the upgrade package over your existing installation. There are no web.config changes to merge and you don’t have to worry about the version_key.txt file or your license information. Get the upgrade package from your downloads page. If you are upgrading from an earlier version, follow the instructions in the Admin Guide.

These are the bugs that are fixed. More details are available on the release history page.

  • Error may occur when case of ASPX file name changes
  • Setting ShowHeader to “true” in embed.aspx results in error
  • Error “Value does not fall within the expected range” when adding or synchronizing certain images
  • Spaces in AD role provider configuration may cause exception
  • Gallery Server may try to add or remove a user to/from a nonexistent role
  • AD role provider may delete roles
  • Downloaded original files may have the wrong file extension
  • AD role provider may generate NoMatchingPrincipalException
]]> 0
Customer post-mortem: Issue with AD groups Fri, 02 Dec 2016 22:01:31 +0000 Today I wrapped up one of the most challenging customer support issues we’ve ever had. In the end, the solution was ridiculously simple (as solutions often are), but it took many hours and misleading clues to get there (as it often does). Here’s the story, along with the twists and turns.

Gallery Server has supported Active Directory authentication for many years but until recently it hasn’t supported integration with AD groups. This is really nice to have in corporate environments because you don’t have to manage a separate set of roles, especially the addition and removal of AD accounts to/from roles. Gallery Server recognizes your AD groups, including their members, and uses them to secure your gallery access. We couldn’t fit this feature into the initial 4.0 release but we announced on our website that it would be available by the third quarter of 2016.

In June 2016, a customer from Norway approached us and asked if they could have early access to the promised support for AD groups. This feature was so important they were willing to pay a priority fee and accept that the feature was in a pre-release state. So we gave it to them and it worked well right out of the box. They were thrilled.

Now fast forward to November. That is, a couple of weeks ago. By that point we had officially released the AD role provider and the customer upgraded their gallery to 4.2.0. But they were having a problem. They stated that after the upgrade, new users could no longer access the gallery. After successfully authenticating with their AD account, they received this message:

Message indicating user is authenticated but does not have access to any albums in the gallery

Gallery Server shows this message when a user is logged in and does not belong to any roles that provide access to the gallery. The first thing I considered was whether Gallery Server was ignoring groups in AD that it was previously recognizing. So I studied the changes between the pre-release code and the production code they were now using, but nothing jumped out at me. Puzzled, I asked the customer to confirm that the pre-release code worked, and he said yes. I verified that the groups had the necessary permissions to albums on the Manage Roles page.

Then I asked for more details about their domain architecture. This is when I learned they had a fairly complex organizational structure:

Active Directory structure of customer's domain

This structure contains many groups spread across many organizational units. To ease management, they used nested groups where one or more groups at each office location were added to a few “master” groups stored in another OU:

Top level OU containing parent AD groups

It is these master groups, not the many child groups, that are configured to be recognized by Gallery Server in the ActiveDirectoryRoleProvider section of the web.config file:

AD group provider configuration in web.config

There is nothing wrong with this architecture. In fact, it is well organized, easy to manage, and supported in Gallery Server. When Gallery Server asks Active Directory for the members of a group, AD recursively processes all member groups and returns a flattened list of users.

The customer claimed that when a new user was added to one of these top level groups, everything worked fine. But when the user was in one of the nested groups, they would get the message shown earlier. With this information, I built a sample of this structure on my test domain to see if I could reproduce the issue. But no matter what I tried, it always worked. That is, Gallery Server would correctly recognize users contained in nested groups.

Around this time, the customer mentioned they were getting an error when they tried to expand a user on the Manage Users page:

Error on the Manage Users page when using the AD group provider

In the event log was the following entry:

System.Configuration.Provider.ProviderException: Unable to query Active Directory.

Stack trace:

at GalleryServer.Web.ActiveDirectoryRoleProvider.GetRolesForUser(String userName)
at GalleryServer.Web.Controller.RoleController.GetGalleryServerRolesForUser(String userName)
at GalleryServer.Web.Controller.UserController.GetUserEntity(String userName, Int32 galleryId)
at GalleryServer.Web.Api.UsersController.Get(String userName, Int32 galleryId)

Inner exception:

System.DirectoryServices.AccountManagement.PrincipalOperationException:  While trying to retrieve the authorization groups, an error (1789) occurred.

Inner exception stack trace:

at System.DirectoryServices.AccountManagement.AuthZSet..ctor(Byte[] userSid, NetCred credentials, ContextOptions contextOptions, String flatUserAuthority, StoreCtx userStoreCtx, Object userCtxBase)
at System.DirectoryServices.AccountManagement.ADStoreCtx.GetGroupsMemberOfAZ(Principal p)
at System.DirectoryServices.AccountManagement.UserPrincipal.GetAuthorizationGroupsHelper()
at GalleryServer.Web.ActiveDirectoryRoleProvider.GetRolesForUser(String userName)

A little googling discovered that error code 1789 means ERROR_TRUSTED_RELATIONSHIP_FAILURE – The trust relationship between this workstation and the primary domain failed. Based on this clue, the customer removed the server from the domain and re-added it. This solved the issue with the users page, but the issue with the nested groups remained.

At this point I asked the customer if they could take a look at my test domain architecture to see if they could help me reproduce the issue. So we set a day and time and used TeamViewer to share the screen. Turns out they thought I accurately modeled their architecture and couldn’t see any reason why it worked for me and not for them.

This was getting frustrating and I was starting to run out of ideas, but I wasn’t ready to give up. I asked them if they could give me access to a PC on their network where I could conduct some tests. They gave me a nice Win7 machine with TeamViewer access. I installed IIS, Visual Studio 2015 Community edition, and the source code for the pre-release version I gave them in June and the latest 4.2.0 code. I wanted to step through the code and compare the working version with the non-working version.

But I hit a stumbling block. When running the code, I got the following exception immediately after logging on:

System.DirectoryServices.AccountManagement.NoMatchingPrincipalException:  An error occurred while enumerating the groups. The group could not be found.

This error was getting thrown from deep within .NET code when enumerating the groups returned by UserPrincipal.GetAuthorizationGroups(). This error was not happening on the web server. It was a new problem I had to resolve before I could continue. Ugghhh. After a bit of googling I found that this error occurs when an SID cannot be resolved. After a bit of experimenting I determined it was just one of the groups that was triggering this issue, so I tweaked the code to silently swallow the exception.

That allowed me to run the code enough where I could confirm the behavior reported by the customer. Sure enough, Active Directory was not returning the expected groups from the GetAuthorizationGroups() method. It was returning some groups, but not all. This caused the RoleProvider.GetRolesForUser() method to return less roles than expected, thereby causing Gallery Server to inaccurately determine the user should not have access to the gallery.

When I ran the pre-release code, it also neglected to return all the groups. That is, I saw the same (incorrect) behavior in both versions of the AD role provider. But wait – the customer said it worked with the pre-release code and not with the latest code. It was challenging to make sense of all of this conflicting information. I had no plausible explanation for how this could have worked with the old code.

At this point I must have spent 10-12 hours troubleshooting with the customer and didn’t have any good theories about what was happening. How could it have worked before? Why did this affect only new users? How do I get it working again?

I wrote up my findings to the customer yesterday. I described how I could not find a difference in behavior between the old code and the new code. I mentioned that I believed other factors outside of Gallery Server were involved that led him to believe that the pre-release code worked. I offered to continue investigating if they could show me pre-release code that worked. And I described how Gallery Server was simply responding to the information given to it by Active Directory. To figure out why AD was returning unexpected results, I suggested bringing in a domain expert or Microsoft Support Services.

And then I said one more thing. A thing I almost didn’t write.

Please check that the AD group is a Security group, not a Distribution group. According to this thread, this can cause the behavior we are seeing.

AD groups that are distribution groups are not returned when you use the GetAuthorizationGroups() method. While that would explain the behavior we were seeing, it didn’t fit the other evidence that (1) the code used to work and (2) only new users are affected. It didn’t seem a likely cause.

But that turned out to be it. One of the AD groups was configured as a distribution group, and as soon as they changed it to a security group, everything worked as expected! The customer let me know he inadvertently gave me incorrect information. It’s not that the code used to work. It never did for users in this one particular AD group. It turned out that the users in that group never tried logging in to the gallery until the most recent upgrade, so the problem only appeared after the upgrade. It’s not clear to me why he thought it affected only new users, but it didn’t.

Lessons learned

This support case was difficult because of incorrect information provided by the customer and my inability to reproduce the issue on my test system. Here are some of the lessons:

  • The AD role provider doesn’t recognize distribution groups. Use security groups.
  • Please be careful with your words when you ask for help. Be sure what you are saying is accurate.
  • Look for patterns in the behavior you see. Run some experiments.
  • If I am unable to quickly resolve your issue, take a pause and reevaluate the behavior you are seeing. Challenge your assumptions.
  • If possible, give me full access to your server right away. Much of the time spent on this issue was taking the customer’s description at face value and trying to reproduce it on my system. That is not going to work if the information is wrong.
  • I repeat – let me log on to your network and server to see the issue for myself. Things get resolved more quickly when I can get at the source. I understand there may be security concerns but if you want to be efficient this is the way to do it. If necessary, use TeamViewer and watch me to assure yourself I’m not getting into trouble.

I’m not upset with the customer. I’ve made plenty of mistakes and wrong assumptions in my life, and more are sure to follow. But this is a good reminder of what we can strive for.

]]> 0