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!
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:
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/
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
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:
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:
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…
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.
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 Clientuninstall.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
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 batch file should contain two lines:
“%ProgramFiles%FileZilla FTP Clientuninstall.exe” /S
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++.