SAGE Accounting Line 10 (and others) cannot run in a non-Administrative account under Windows 2000 / XP

System Requirements:

  • SAGE Line 10
  • Windows 2000

The Problem:

If you are attempting (or have) rolled out SAGE 10 onto your system, then you will have had the misfortune to find that if you attempt to run it in an account below that of Power User on the local system, it will not work.

SAGE either locks up at the application initialisation, flashes up and crashes or if you have by some fluke got a semi-valid set of system privileges it will refuse to let you log-in under any user account, including the ‘manager’.

The Fix:

It seems absurd that this application even shipped, and yet it did. The problem will only happen on NTFS volumes, if you have any FAT32 systems you’ll have found out by now that they work. Sage installs into the Administrative account, and as such it creates its folder set using Administrative permissions.

The problem is in effect very simple, but is completely undocumented anywhere and required some good old fashioned forensic work to suss!

In order to get it to work you need to re-jig the NTFS permissions. Please note that I have used “Advanced” permission terminology in an attempt to lock the process down as much as possible.

C:\Program Files\Sage\Accounts\
Effective Permissions: Write/Create/Delete

C:\Program Files\Sage\Accounts\ACCDATA\
Effective Permissions: Modify

C:\Program Files\Sage\Accounts\TaskOpt\
Effective Permissions: Modify

C:\Windows\Sage.ini
Effective Permissions: Write
Note: If it doesn’t exist, create it using notepad

C:\Windows\System32\sglch32.usr
Effective Permissions: Create

C:\Windows\System32\sageinformer50.ssf
Effective Permissions: Create

Windows Update / Microsoft Update fails with error 0x80072EFD when running McAfee Virus Scan Enterprise 8.0i

System Requirements:

  • Windows 2000 SP4 + BITS 2.0
  • Windows XP SP2
  • McAfee Virus Scan Enterprise 8.0i

The Problem:

This is one of those irritations that could (and should) have been sorted immediately, but lingered for months with a really very simple solution.

When you are using a suitably equipped version of Windows and happen to have McAfee Virus Scan Enterprise 8.0i (Confirmed on Patch 11 and 15, but should apply to any patch version and 8.5i) installed, your computer(s) fail to receive automatic updates through the AUClient Windows Automatic Updates service. In addition, if you attempt to access Windows Update or Microsoft Update, the update detection fails with error code 0x80072EFD.

All contemporary fixes / Microsoft suggestions to fix this fail to resolve the problem.

The Fix:

This is well and truly McAfee’s responsibility, it isn’t their fault – but it is what you get when you blur the line between an anti-virus product and a firewall.

I could argue the point that some foresight in providing some foresight in the product on this, or some reference to the issue on their knowledge base would have been useful, particularly as this ‘issue’ impacts users connecting both to the web based WU/MU and any corporate SUS system.

McAfee Virus Scan has a non-default option to inhibit port 80 downloads from non-approved executives. If through group policy, custom installation script, or distribution agreement (as with local authority school distributions of Network Associates McAfee AV) this policy has been enabled, then the Automatic Updates service is prevented from connecting to the Internet and downloading catalogue information.

Internet Explorer sessions to SUS/WU/MU are impacted because as of version 5 server connections they now rely upon the Automatic Updates service and the Background Intelligent Transfer Service (BITS) to make use of Windows Update.

To fix the error you have two options:

  1. Disable to McAfee Access Protection Policy
  2. Add the Service Host process wrapper used by the AU/BITS services to the approved connections list

 

Disable the Access Protection Policy

  1. Open Virus Scan Console as an Administrator
  2. Right click Access Protection
    Virus Scan Console: Access Protection
  3. Choose Properties
  4. Remove the check mark next to “Prevent Downloads from the World Wide Web”
    Access Protection
  5. Click OK

 

Approve the AU/BITS service to perform port 80 downloads

Both the Automatic Updates service and BITS service run as part of the Service Host Process wrapper service (as do many other system services), therefore you must allow the Service Host download permission to resolve this problem without fully disabling the McAfee policy.

As an administrator you should consider this carefully and ensure that if nothing else McAfee is patched and receiving updates properly. If your systems are not adequately protected, they may be vulnerable to exploitation by the plethora of Service Host process resident malware applications and viri, which can potentially embed themselves into a Service Host process. As a direct consequence of disabling this policy any such code will by default receive port 80 (the only port by default) download access.

Disabling through the Interface

  1. In the Access Protection configuration in Virus Scan Console, highlight “Prevent Downloads from the World Wide Web” and click the edit button
  2. Add ‘svchost.exe’ (without the ‘ ) to the exceptions list
    Block Range
  3. Click OK

Disabling through the registry

The fastest way to sort it is to distribute the registry change through group policy (or similar). The information below is correct for VSE 8.0i Patch 15.

HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\TVD\Shared Components\On Access Scanner\BehaviourBlocking
REG_SZ: PortBlockWhiteList_3
Value: (see below for overview of the required change)

McAfee Vanilla Install Settings:
outlook.exe,msimn.exe,iexplore.exe,mozilla.exe,netscp.exe,opera.exe,thunderbird.exe,msn6.exe,neo20.exe,mobsync.exe,waol.exe,nlnotes.exe

Required Change based upon Vanilla Install:
outlook.exe,msimn.exe,iexplore.exe,mozilla.exe,netscp.exe,opera.exe,thunderbird.exe,msn6.exe,neo20.exe,mobsync.exe,waol.exe,nlnotes.exe,svchost.exe

Error: “Setup failed while installing sub-component Exchange ActiveSync with error code 0xC0070643 (please consult the installation logs for a detailed description). You may cancel the installation or try the failed setup again.” while installing Exchange 2003 SP2

System Requirements:

  • Exchange Server 2003, SP2
  • Windows 2000, 2003 Server

The Problem:

When attempting to install Exchange Server 2003 Service Pack 2 (SP2) you receive the following error message:

Setup failed while installing sub-component Exchange ActiveSync with error code 0xC0070643
(please consult the installation logs for a detailed description).
You may cancel the installation or try the failed setup again.

The installation halts at a retry prompt or aborts and continues the installation normally.

More Information:

Microsoft basically screwed up in their version number catching during scripting and testing of the SP. If you have followed my Windows patching guides on HPC:Factor, your Exchange 2003 SP2 install will by default experience this issue; not because I screwed up, but because Microsoft clearly don’t think any of you ever update anything other than the half-hearted list generated by Windows Update.

Credit for the time on this one goes without me stealing the lime-light to the ‘SBS Diva‘, but her explanation for the issue is incorrect. The issue isn’t Shavlik’s, it’s Microsoft’s.

After a little digging, I discovered that the Exchange 2003 RTM shipped with MSXML Core Service 3.0 SP2. This is understandable, as Windows 2000 SP3/SP4 with Internet Explorer 5.01 SP3/SP4 lacks this module (Internet Explorer 6.0 SP1 ships with SP3). However, Service Pack 2 for Exchange Server ships with MSXML Core Service SP5, Service Pack 7 (SP7) was released a month later.

The Exchange SP Installer is simply expecting to find a lower version of MSXML for the Exchange ActiveSync system (SP2/3/4). If it encounters the same or higher version, the installer errors out believing the installation to have erroneously failed, when in reality it was just badly written.

The Fix:

Just as stated by SBS Diva, if you purge the version check (which is done against the Windows Installer versioning, not the file version) backup and then delete the key for MSXML 3.

MSXML 3.0 SP5 – [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\45D60EC31B272B44BA064E72E78CE04F]
MSXML 3.0 SP7 – [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\E83E246D42D0C684A9D23E61DD96F6B4]

There is no MSXML 3.0 SP6.

 

Vignette 1: If you do perform a visual search of HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products, ensure that you are not deleting MSXML 4.0, 5.0 or 6.0 related entries. It is also possible for MSXML 2.x to be installed on the system (though unlikely unless your install is as old as Windows 2000 itself)

Vignette 2: The Exchange SP2 installer is going to leave the system *thinking* that it has SP5 installed on it. If you started on SP5, fine, but if you were on SP7, you should put the hive back again or reinstall SP7. For SP5 users, I recommend installing SP7 after Exchange is up and running. The Exchange SP installation process does not devolve the MXSML level back to SP5.

Error: Activex componet can not create object: “WScript.Shell” when running WScript application

System Requirements:

  • Windows 95, 98, 98SE, Millennium
  • Windows NT 4.0, 2000, XP, 2003, Vista

The Problem:

When you run a .vbs file with a call to CreateObject(“WScript.Shell”) the script/application terminates with the follow error message:

ActiveX componet can not create object:”WScript.Shell”
Code: 800A01AD

The script then exits

More Information:

Your Windows Scripting Host has a mis-registered control. If you have just Installed Microsoft Internet Explorer <anything>.<anything> chances are the install went wrong. Check the install log in %SystemRoot% and check for failures.

I would recommend reinstalling IE properly to be safe, but chances are the problem will still be there afterward (it was with this particular muse and MSIE 7.0).

The fix is very simple however (assuming that your error is down to Windows Scripting Host and not bad programming; you are on your own on that one).

From cmd, or from a .bat run:

regsvr32 dispex.dll
regsvr32 jscript.dll
regsvr32 scrobj.dll
regsvr32 scrrun.dll
regsvr32 vbscript.dll
regsvr32 wshcon.dll
regsvr32 wshext.dll
regsvr32 wshom.ocx

I recommend that you start with wshom.ocx and test . No reboot is required for shell initiated .vbs files. If the problem is with IIS, you should restart the IIS Administrative and WWW services.

Be sure that you are using WScipt 5.6 (Unless running Vista or XP with IE7). You can download the latest release here: