It was great to see that the Windows Admin Center is now being updated automatically with other Windows Server OS updates when I updated the server on which it is installed the other day:
One fewer thing to have to check for manually!
Azure AD Connect–Upgrade to 1.1.533.0 and Change of Source Anchor to mS-DS-ConsistencyGuid
As I blogged yesterday, I upgraded our instance of Azure AD Connect to what was, at the time, the latest version, 1.1.524.0. Subsequently, Microsoft Security Advisory 4033453 was published indicating that an upgrade to version 1.1.533.0 was very strongly recommended.
As before, the upgrade went smoothly, however there were a couple of additional points of note during the upgrade:
- Running the Azure AD Connect msi gave the following warning (note that I appended the version number to the file name in this example):
I’m assuming that this will be fixed shortly
- Once the upgrade was complete, the following warning was shown:
’Azure Active Directory is configured to use AD attribute objectGUID as the source anchor attribute. It is strongly recommended that you let Azure manage the source anchor for you. Please run the wizard again and select Configure Source Anchor.
Re-running the wizard and selecting the ‘Configure Source Anchor’ task allowed Azure AD Connect to pick ‘mS-DS-ConsistencyGuid’ as the source anchor, and all configuration occurs automatically. At the end of the process however another warning is shown indicating that if ADFS is managed externally to Azure AD Connect, then claim rule changes are required to align the new Source Anchor with the value returned and users may not be able to log in unless these changes are made.
In our case, this means that changes need to be made to the ADFS rules for the Office 365 relying party trust.. To make these changes, the following steps were taken:- On the ADFS Server, expand ADFS, then Trust Relationships, then click on Relying Party Trusts. Right-click the ‘Microsoft Office 365 Identity Platform’ and select ‘Edit Claim Rules…’:
- Select rule 1 and click the ‘Edit Rule…’ button.
- The original rule was:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);
The only change that was required was to change objectGUID to mS-DS-ConsistencyGuid, I.e.
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,mS-DS-ConsistencyGuid;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value); - Save the rule and double-check that you can authenticate to Office 365.
- On the ADFS Server, expand ADFS, then Trust Relationships, then click on Relying Party Trusts. Right-click the ‘Microsoft Office 365 Identity Platform’ and select ‘Edit Claim Rules…’:
Some background to the issue of ImmutableID and the value to select for Source Anchor for Office 365 can be found at https://blog.msresource.net/2015/05/20/revisiting-the-microsoft-online-immutable-id-design-decision/
Test-SPContentDatabase False Positive
I was recently performing a SharePoint 2013 to 2016 farm upgrade and noticed an interesting issue when performing tests on content databases to be migrated to the new system.
As part of the migration of a content database, it’s usual to perform a ‘Test-SPContentDatabase’ operation against each database before attaching it to the web application. On the farm that I was migrating, I got mixed responses to the operation, with some databases passing the check successfully and others giving the following error:
PS C:\> Test-SPContentDatabase SharePoint_Content_Share_Site1
Category : Configuration
Error : False
UpgradeBlocking : False
Message : The [Share WebSite] web application is configured with
claims authentication mode however the content database you
are trying to attach is intended to be used against a
windows classic authentication mode.
Remedy : There is an inconsistency between the authentication mode of
target web application and the source web application.
Ensure that the authentication mode setting in upgraded web
application is the same as what you had in previous
SharePoint 2010 web application. Refer to the link
“http://go.microsoft.com/fwlink/?LinkId=236865″ for more
information.
Locations :
This was interesting as all of the databases were attached to the same content web application, and had been created on the current system (I.e. not migrated to it from an earlier version of SharePoint) and therefore should all have been in claims authentication mode. Of note also is the reference to SharePoint 2010 in the error message, I guess the cmdlet hasn’t been updated in a while…
After a bit of digging, it turned out that the databases that threw the error when tested had all been created and some initial configuration applied, but nothing more. Looking into the configuration, there were no users granted permissions to the site (except for the default admin user accounts that had been added as the primary and secondary site collection administrators when the site collection had been created), but an Active Directory group had also been given site collection administrator permissions.
A quick peek at the UserInfo table for the database concerned revealed the following (the screen shot below is from a test system used to replicate the issue):
The tp_Login entry highlighted corresponds to the Active Directory group that had been added as a site collection administrator.
Looking at Trevor Seward’s blog post ‘Test-SPContentDatabase Classic to Claims Conversion’ blog post showed what was happening. When the Test-SPContentDatabase cmdlet runs, it’s looking for the first entry in the UserInfo table that matches the following rule:
- tp_IsActive = 1 AND
- tp_SiteAdmin = 1 AND
- tp_Deleted = 0 AND
- tp_Login not LIKE ‘I:%’
In our case, having an Active Directory Group assigned as a site collection administrator matched this set of rules exactly, therefore the query returned a result and hence the message was being displayed, even though the database was indeed configured for claims authentication rather than classic mode authentication.
For the organisation concerned, having an Active Directory domain configured as the site collection administrator for some of their site collections makes sense, so they’ll likely experience the same message next time they upgrade. Obviously in this case it was a false positive and could safely be ignored, and indeed attaching the databases that threw the error to a 2016 web application didn’t generate any issues.
Steps to reproduce:
- Create a new content database (to keep everything we’re going to test out of the way).
- Create a new site collection in the new database adding site collection administrators as normal.
- Add a domain group to the list of site collection administrators.
- Run the Test-SPContentDatabase cmdlet against the new database.
Steps Required to Configure WSUS to Distribute Windows 10 Version 1511 Upgrade
Microsoft recently made a hotfix available that patches WSUS on Windows Server 2012 and 2012 R2 to allow Windows 10 upgrade to version 1511. Installing the update is not, however, the only step that is required…
- Install the hotfix. This can be downloaded from https://support.microsoft.com/en-us/kb/3095113. Ensure that you pick the appropriate hotfix for the version of Windows Server on which you’re running WSUS. Note that if you’re running Windows Server 2012 R2, there’s also a pre-requisite install.
- Once the hotfix is installed and you’ve restarted your WSUS server, look in the ‘Products and Classifications’ option under the Classifications tab and ensure that the checkbox for upgrades is selected. This is not selected automatically for you:
Note that the upgrade files may take quite some time to download to your WSUS server at the next synchronisation. - Add a MIME-Type for ‘.esd application/octet-stream’ in IIS on the WSUS server. To do this:
Open IIS Manager
Select the server name
From the ‘IIS’ area in the centre of IIS Manager, open ‘MIME Types’
Click ‘Add…’
Enter the information above:
Click OK to close the dialog.
Note: Without this step, clients will fail to download the upgrade with the following error:
Installation Failure: Windows failed to install the following update with error 0x8024200D: Upgrade to Windows 10 [SKU], version 1511, 10586. - Approve the Upgrade for the classes of computer in your organisation that you want to be upgraded.
Once all of the above steps are in place, computers that are targeted for the upgrade should have this happen automatically at the next update cycle.
Deploying FileZilla with Configuration Manager 2012 R2
Some time ago I created an System Center Configuration Manager (SCCM) application to deploy FileZilla for users. Recently I created an updated application that upgraded FileZilla (using the usual ‘uninstall the old version, then install the new version’ method), which gave me an error when the application was upgraded:
with the reported error being ‘The software change returned error code 0x87D00325 (-2016410843).
In addition, attempting to uninstall the application using the SCCM Software Center on the client machine gave a ‘Removal Failed’ with the same error details:
Digging through the AppEnforce log file on the client, an error was reported when attempting to uninstall the application as part of the change:
Prepared command line: “C:\Program Files (x86)\FileZilla FTP Client\uninstall.exe” /S
Post install behavior is BasedOnExitCode
Waiting for process 1616 to finish. Timeout = 120 minutes.
Process 1616 terminated with exitcode: 0
Looking for exit code 0 in exit codes table…
Matched exit code 0 to a Success entry in exit codes table.
Performing detection of app deployment type FileZilla 3.13.0 x86
Discovered application
App enforcement completed (0 seconds) for App DT “FileZilla 3.13.0 x86”
This indicates that the uninstall process completed, but the application was detected as still being installed immediately afterwards. This is due to the way that uninstallation is performed, with the uninstall process triggered by SCCM spawning another process to actually perform the uninstallation, while the original process terminates. This means that the process that SCCM is waiting on to complete, does so almost immediately, while the actual work to perform the uninstallation is on-going, hence the reason that SCCM then detects the application as still present on the client system.
To get around the issue, we need to wait a period of time after the uninstallation is triggered to allow for completion before allowing SCCM to perform its detection. In order to do this, I’m using the ‘sleep.exe’ program that comes with the Windows 2003 Resource Kit Tools (available at http://www.microsoft.com/en-us/download/details.aspx?id=17657) to achieve this.
The items we’ll need to be copied to an appropriate location for deployment are:
- The FileZilla installer
- The sleep.exe program
- A batch file to perform the uninstallation
- An SCCM application that uses the batch file
The batch file should contain two lines:
“%ProgramFiles%\FileZilla FTP Client\uninstall.exe” /S
Sleep 20
This runs the uninstaller as before, then pauses for 20 seconds to allow the system to catch up. 20 seconds is long enough for our client machines, YMMV.
The SCCM application should then be created as normal:
Manually specify the application information:
Provide a name for the application and optionally a publisher, version etc.:
Provide appropriate information for the Application Catalog:
Click ‘Add…’ to add a Deployment Type to the application:
Select ‘Manually specify the deployment type information’:
Provide a deployment type name and optionally administrator comments:
For the content page of the wizard, specify the content location, for the installation program, specify ‘FileZilla_X.XX.X_win32-setup.exe /S’ and for the uninstall program, specify the batch file that was created previously:
For the detection rules, we used the file version of the ‘filezilla.exe’ program file that gets installed, which seemed to work well:
In addition, if required, supersedence information can be added to the application.
The procedure above provided a robust SCCM application that can be installed and uninstalled without issue and can also be upgraded to a later version without issue. It should be noted that this method works for other applications with the same sort of uninstallation routine, e.g. Notepad++.