“Cannot connect to Primary Server” from Mac OS X clients running Sophos Anti-Virus 8.x after the Enterprise Console has been updated to distribute Anti-Virus 8/9 for OS X via a HTTP connection served through IIS 6, 7, 7.5, 8

System Requirements:

  • Sophos Enterprise Console 5.2.1
  • Mac OS X 10.4+

The Problem:

If you have been deploying Sophos Enterprise Console 5 to update Mac OS X using a HTTP connection, end devices may start refusing to connect to the Primary server. The Sophos Anti-Virus 8 log will state that it was unable to connect to the server.

Windows clients can update successfully from the same server over HTTP.

More Info

In this particular case, the HTTP distribution point was backed from a public facing web server running IIS 7.5 under Windows Server 2008 R2. The server has an encrypted tunnel connection and read-only pass through authentication to a SMB share on an internal security server running Windows Server 2008 SP2 and Sophos Enterprise Console 5.2.1.

The SMB share is the same as the one exposed to the internal LAN for direct SMB updating and Windows clients using either HTTP or SMB will update successfully.

Mac OS X 10.7, 10.8 or 10.9 clients were however locked at Anti-Virus 8.0.5 and were only receiving definition updates from the secondary server at Sophos. The client will connect to the Primary HTTP share and begin to download, but terminate after a few kilobytes have been transferred.

The Fix

Somewhere between 8.0.5 and the current 9.0.5, there would appear to have been a change in the internal structure of the Sophos Anti-virus .mpkg.

Enable directory browsing and test that you can open the following file:

/SophosUpdate/CIDs/S000/ESCOSX/Sophos Anti-Virus.mpkg/Contents/_CodeSignature/CodeDirectory

Note that CodeDirectory is a file and not a folder. This is the root of the problem.

Under the default metabase configuration in IIS, IIS will only serve files with known extensions and registered MIME types. So what happens with file with no file extension? By default a 404 error.

Under IIS 6

  1. Right click your servicing web site in IIS manager and choose Properties
  2. Go to the HTTP Headers tab and choose MIME Types
  3. Click New…
  4. In Extension type:
    .*
  5. In MIME type type:
    application/octet-stream
  6. Commit all changes

Under IIS 7

  1. Select the servicing web site in IIS manager
  2. Choose MIME Types under the IIS heading
  3. Click Add… in the top right
  4. In File name extension type:
    .*
  5. In MIME type type:
    application/octet-stream

Under IIS 7.5 / 8

  1. Select the servicing web site in IIS manager
  2. Choose MIME Types under the IIS heading
  3. Click Add… in the top right
  4. In File name extension type:
    .
  5. In MIME type type:
    application/octet-stream

Under IIS 7, 7.5, 8 you may also need to add the following to your root Web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering>
<fileExtensions allowUnlisted="true" />
</requestFiltering>
</security>
</system.webServer>
</configuration>

“StartServiceCtrlDispatcher failed (error 6)” is returned from attempting to start SQL Server Agent and “System.NullReferenceException: Object reference not set to an instance of an object.” is returned when attempting to start SQL Server Agent in SQL Server Management Studio

System Requirements:

  • Microsoft SQL Server 2008

The Problem:

It’s another instance of a new SQL Server installation on a newly installed Windows Server system that refuses to do what it is supposed to do. It seems to me that this is the rule rather than the exception, but I digress.

If you pull up a command prompt and attempt to manually start the SQL Server Agent process e.g.

"F:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\SQLAGENT.EXE" -i MSSQLSERVER

You will receive

StartServiceCtrlDispatcher failed (error 6)

Similarly, if you attempt to start the SQL Server Agent inside SQL Server Management Studio you will receive the ubiquitous

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.

Server stack trace:
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ObjectExplorer.FindObjectExplorerFrame()
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ObjectExplorer.GetObjectExplorer(Boolean activateWindow)
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ObjectExplorer.ShowError(Exception e)
at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.Service.Start()
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)

In addition if you check the SQL Server Logs, the current log for SQL Server Agent will be blank or will have nothing logged recently (this is important)

More Info

If you are seeing up to date events in the SQL Server Agent log, then this fix likely does not apply to your situation. If you have a blank or a stationary log file then chances are it does.

Basically, the SQL Server Agent is refusing to start because it cannot write TO the log file. Obviously it is extremely hard to have the process termination log or output that fact otherwise Microsoft would have done it already… sigh.

The Fix

It is probably either or both of:

  1. Check the error log file path for accuracy
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.MSSQLSERVER\SQLServerAgent
    Reg_SZ: ErrorLogFile
  2. Check the file / folder permissions for the path stated above, the SQLAGENT.OUT file and the SQLAGENT.# files. You can either reset them so that the SQL Server Agent’s process account has Full Control access or (depending on your logging policy) delete the files and SQL Server Agent will re-create the logs at startup

PEAR for PHP Error “No releases available for package “xxx” install failed” after running ‘pear install xxx’ on Windows Server 2008

System Requirements:

  • Windows Vista
  • Windows 7
  • Windows Server 2008, 2008 R2

The Problem:

You know that something a bit odd is going on when one of a batch of servers starts throwing errors that the others sailed past. In this case trying to configure PEAR for a new PHP install with Mail, Mail_Mime and Net_SMTP (pear.php.net/mail, pear.php.net/mail_mime and pear.php.net/net_smtp) should be fairly standard. The other servers took the install and even this server too Mail and Mail_Mime but would not accept Net_SMTP returning:

C:\Program Files (x86)\PHP>pear install net_smtp
No releases available for package “pear.php.net/net_smtp”
install failed

Leaving it overnight before rolling up my sleeves (in case it was just downtime at the package repository) the fix was fairly simple.

The Fix

If you are experiencing the same problem this server was having, running the following

pear remote-list

Will result in

SECURITY ERROR: Will not write to C:\Users\<user[8.3]>\AppData\Local\Temp\pear\cache\e9b88593398eb79a9aa91024351d646arest.cacheid as it is symlinked to C:\Users\<user>\AppData\Local\Temp\pear\cache\e9b88593398eb79a9aa91024351d646arest.cacheid – Possible symlink attack

If you get something akin to the above simply browse to:

C:\Users\<user>\AppData\Local\Temp\

and delete the pear folder

“Service reached limit of transient errors. Will shut down. Last error returned from Service Manager: 0x80029c4a” when trying to install .net Framework 3.0 on Server 2008 or .net Framework updates from Windows Update

System Requirements:

  • Windows Vista
  • Windows 7
  • Windows Server 2008, 2008 R2

The Problem:

So we had a server with a corrupted .net installation, Windows Update kept on trying to install a .net 3.5 QFE and failed it, which showed up on the SUS server error logs. Investigation revealed that it would not install the update.

After running the .net cleaner utility, Windows Update still insisted that the machine needed the QFE – despite the fact that .net 4, 3.5, 3.0, 2.0 and 1.x were not installed.

The next obvious step was to put .net back on the machine, starting with 3.0 in the Windows Server Manager ‘Features’ list. It would not reinstall the feature however terminating with

Service reached limit of transient errors. Will shut down. Last error returned from Service Manager: 0x80029c4a

There were two problems here

  1. A .net Framework update was stuck in the Windows Update Catalogue and could not be cleared (even by purging SoftwareDistribution)
  2. The .net Framework 3.0 feature could not be reinstalled onto the operating system via Windows Server Manager

The Fix

In this instance the following solved the problem:

  1. Browse to:
    C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG
  2. Check to see if there is a machine.config file present within the folder
  3. If there is not, make a copy of machine.config.default in the same folder and rename it to machine.config

Note that you may need to look through other folders under C:\Windows\Microsoft.NET\Framework for this .config file as the ‘v2.0.50727’ part changes with the service release.

 

Once this was done, .net 3.0 could be reinstalled from Windows Server Manager. Once that was done .net 3.5 SP1 could be reinstalled (along with .net 2.0 SP2 and .net 3.0 updates). This allowed the stuck update to actually install and cleared the original error from WSUS.

After that .net 4.0 went back on and everything on the server was back to normal again.

…the toe bone connected to the foot bone, and the foot bone connected to the ankle bone, and the ankle…