Windows Admin Center Updating Automatically

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:

Windows Admin Center Update in Updates List

One fewer thing to have to check for manually!

Offline Domain Join with Direct Access

I was recently in the position that I needed to rebuild a workstation at a remote location, but wanted to end up with it joined to the domain, and able to install software via the SCCM Software Center. Enter Offline Domain Join (djoin.exe)!

Offline Domain Join allows the creation of a machine account and the establishment of a trust relationship between a computer running Windows and a Domain. As part of the process, group policy information can also be transferred to the machine that will be joined to the domain.

Assuming Direct Access is available, the appropriate group policy information for Direct Access can be transferred as part of the process, and this should then allow the remote machine to establish a connection to the domain and from there all remaining group policy information can be transferred, the Configuration Manager client installed etc.

Information on ‘djoin.exe’ including examples for use can be found at https://technet.microsoft.com/en-us/library/offline-domain-join-djoin-step-by-step

My scenario was:

  • The machine account already existed in the correct OU and was a member of the appropriate groups for Direct Access (the machine name had already been used; this was a rebuild) and therefore I needed to use the ‘/reuse’ parameter.
  • The only group policy information I wanted to transfer to the remote machine was for Direct Access. I anticipated that all other group policy information would be transferred automatically once a Direct Access connection had been established.

In my case, the command I used on the provisioning server were:

djoin /provision /domain domain.com /machine MyWorkstation /savefile MyWorkstation-blob.txt /reuse /policynames “Direct Access Client”

The resultant blob should be transferred securely – take note of what the TechNet page says on the matter:

The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.

On the remote workstation, the command I used was:

djoin /requestODJ /loadfile MyWorkstation-blob.txt /windowspath %SystemRoot% /localos

At this point you’re prompted to reboot the workstation. Once the reboot was complete, I left the machine for a few minutes to allow it to establish a connection, then signed in. Everything worked as anticipated and I could log in as a domain user and a Direct Access connection was established. Following a group policy update, the Configuration Manager client was transferred and installed, and a short time later the Software Center became available and I could add software made available from SCCM.

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:

Application Upgrade Filaed

Unable to make changes to your software

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:

FileZilla Removal Failed

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:

Manually specify the application information

Provide a name for the application and optionally a publisher, version etc.:

Provide a name for the application and optionally a publisher, version etc.

Provide appropriate information for the Application Catalog:

Provide appropriate information for the Application Catalog

Click ‘Add…’ to add a Deployment Type to the application:

Click ‘Add…’ to add a Deployment Type to the application

Select ‘Manually specify the deployment type information’:

Select ‘Manually specify the deployment type information’

Provide a deployment type name and optionally administrator comments:

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 content page of the wizard, specify the content location, installation program and uninsatll program

For the detection rules, we used the file version of the ‘filezilla.exe’ program file that gets installed, which seemed to work well:

For the detection rules, use the version of the 'filezilla.exe' file

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++.