Tuesday, November 24, 2009

11/24/09

The Windows System Defender malware/virus has an interesting new trick to stop/disable the Task Manager, as well as other programs like Trend antivirus.

It adds hundreds of entries in the
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options] registry key.

The added entries will have the name of a particular program (image file) with a debugger setting to svchost.exe, like this:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe]
"Debugger"="svchost.exe"

This starts svchost.exe as the debugger whenever the program starts. Since I haven't done any debugging, I don't know if using an invalid debugging program (svchost.exe in this example) will cause the program to fail on startup - essentially stopping it from starting - or if it will run hidden from the user. Either way, it stops you from being able to see the Task Manager. It also will disable the Trend Micro OfficeScan client, as well as others.

There are hundreds of programs that are disabled by Windows System Defender using these registry entries. I didn't look at all of them, but many look like a lot of the usual malware suspects. So, it disables all of the competing malware products that might be on your machine so that it can have exclusive use of your CPU. How nice.

I cleaned them manually (tedious), but I believe Malware Bytes is now aware of this trick & can be used to clean up the registry once you've cleaned up the main stuff. I used Malware Bytes to clean up the rest of files first by pulling the harddrive and using a USB adapter to connect the drive to another machine. MB lets you choose which drive(s) to scan, so you can scan an external drive. You may have to add write permissions back to the hosts file for your user so that you can clean that up (or to delete it & create a new one).



BTW, the following registry entry is a standard Windows registry value & does not need to be removed:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Your Image File Name Here without a path]
"Debugger"="ntsd -d"
"GlobalFlag"="0x000010F0"

Thursday, October 29, 2009

10-29-09

iNews Wires Not Working
AP AP Express Fox CNN

If the Data Receiver computers are restarted, the wire services in iNews will stop functioning.

The iNews console will display the following message repeatedly:
"No configured WS resources for AP" (or whichever wire service is down).

At the console, type in:
List C News

That will provide a list of wire services and their respective numbers, like this:
DEV DEVICE_TYPE COMPUTER CCU PRINTER SPEED OPTIONS DEVNAME
w51 news A-net AP
w52 news B-net AX
w53 news A-net FX
w54 news B-net CN

This tells me that the AP & Fox wires are on Server A and that the AP Express & CNN wires are on Server B.
It also tells me that the AP wire is wire 51, AP Express is 52, Fox is 53, and CNN is 54.

To restart the wire service & get the wires working again, type:
Stop XX
where XX is the 2 digit number of the wire in question. E.g.,
Stop 51
would stop the AP wire service on the iNews server.
It will automatically restart when the next wire story comes in.

You have to type the command in on its respective server. So, if I want to stop wire service 52, I have to switch to the B side first and then type in Stop 52.

Go back to the Data Receiver machine & launch the Data Receiver Administration Application & check to see if wire stories are coming in. Open the iNews client on a machine & check the wires queues to see if new stories are coming in. It's been my experience that missed stories will start coming in once the wire service is restarted on the server.

Tuesday, April 7, 2009

4-7-09

I’ve put together a VBScript that will read a registry value from every machine in a domain & output the results to a file. I chose a .csv file so that the results could be sorted in Excel.

I created this script to give me a list of the Trend update servers our machines are connecting to, but the script can easily be modified to check any registry value. You can also modify the output file name & location easily. The domain name is part of an LDAP query, so I couldn’t make that a variable. You’ll have to find where “DC=domain,DC=com” is in the script & modify with your domain info.

When you launch the script, it will tell you where the output file will go. When the script has finished, it will generate a message box telling you that it is finished & where the file is (again). The output file will give you a list of machines and the Trend server that they are updating from. If Trend is not installed, the resulting field will be blank. If a machine is unreachable, the resulting field will be an error message.

It takes a while for it to run, since it will wait & time out on every machine that is not reachable.

--------------------------------------------------------------------------

'This script will display a registry value for all computers on your domain

Const ADS_SCOPE_SUBTREE = 2
Const OPEN_FILE_FOR_WRITING = 2
Const ForReading = 1
Const HKEY_LOCAL_MACHINE = &H80000002 'HKLM hive
Const CompKey = "SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName"
Const CompValue = "ComputerName"

strRegKey = "SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion\Misc."
strRegValue = "UpdateFrom"

strDirectory = "C:\"
strFileName = "TrendUpdateServers.csv"
strWritePath = strDirectory & strFileName

On Error Resume Next

Wscript.Echo "The output will be written to " & strWritePath

Set objFSO1 = CreateObject("Scripting.FileSystemObject")

If objFSO1.FileExists(strWritePath) Then
Set objFolder = objFSO1.GetFile(strWritePath)

Else
Set objFile = objFSO1.CreateTextFile(strWritePath)
objFile = ""

End If
Set fso = CreateObject("Scripting.FileSystemObject")
Set textFile = fso.OpenTextFile(strWritePath, OPEN_FILE_FOR_WRITING)

' Header Row
textFile.WriteLine ("Machine Name, Result")

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"

Set objCOmmand.ActiveConnection = objConnection
objCommand.CommandText = _
"Select Name, Location from 'LDAP://DC=domain,DC=com'"_
& "Where objectClass='computer'"
objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
Set objRecordSet = objCommand.Execute
objRecordSet.MoveFirst

Do Until objRecordSet.EOF
' Wscript.Echo "Computer Name: " & objRecordSet.Fields("Name").Value
' textFile.WriteLine(objRecordSet.Fields("Name").Value)
strComputer = (objRecordSet.Fields("Name"))
' WScript.Echo strComputer

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
strComputer & "\root\default:StdRegProv")

IF Err <> 0 Then
' WScript.Echo strComputer & " generated the following error: " & Err.Description
textFile.WriteLine (strComputer & ", " & Err.Description)
Err.Clear

Else

oReg.GetStringValue HKEY_LOCAL_MACHINE, CompKey, CompValue, strActiveName

' oReg.GetDWordValue HKEY_LOCAL_MACHINE, strRegKey, strRegValue, intNumber
oReg.GetStringValue HKEY_LOCAL_MACHINE, strRegKey, strRegValue, strTrendServer

' textFile.WriteLine (strActiveName & ", " & intNumber)
textFile.WriteLine (strActiveName & ", " & StrTrendServer)
End If
objRecordSet.MoveNext

Loop

WScript.Echo "Finished! The output has been written to " & strWritePath

Thursday, April 2, 2009

4-2-09

We had a number of machines that were not showing up on the WSUS console. All machines are pointed to WSUS using an Active Directory (AD) Group Policy Object (GPO), so there wasn't any difference there to troubleshoot. Looking at the registry on the client machines, the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate settings were correct for our WSUS server and the Automatic Updates & BITS services were enabled and running. Running wuauclt.exe /resetauthorization /detectnow from a command prompt didn't fix the problem computers. The c:\Windows\WindowsUpdate.log file showed that the clients were contacting our WSUS server & even doing updates. The WSUS Client Diagnostics Tool (from here: http://technet.microsoft.com/en-us/wsus/bb466192.aspx ) showed no issues connecting to our server.

I found this solution on the internet:

5. Imaged clients with a duplicate client ID will only appear once in the WSUS Admin Console. Each AU client must have a unique id which is created for each individual install. When imaging systems it is recommended always to use SysPrep. The WSUS admin console will only display one client for each unique ID. If you have multiple clients created from one image which are sharing the same ID, only one will appear in the WSUS admin console. All clients will check in and download updates, but only one will appear and display status in the WSUS admin console. In cases where clients are not checking in, and they were created from images without running SysPrep, the following steps will reset the existing duplicative client IDs.

a. Run regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
b. Delete the PingID, SUSClientID and the AccountDomainSID values
(on our machines, AccountDomainSID didn't exist, but SUSClientIdValidation did. I deleted PingID, SUSClientID, and SUSClientIDValidation)
c. Stop and start the Wuauserv Service
d. From the command prompt run: wuauclt /resetauthorization /detectnow

or-

From the command line, once you are sure the AU client is properly configured and not disabled, you could run a batch file (which might look something like this sample) and get the same results:

rem Fixes problem with client machines not showing up on the server due to imaging method

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v AccountDomainSid /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v PingID /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
cls
@echo Triggering detection after resetting WSUS client identity
net stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow

source:
http://www.wsuswiki.com/ClientFAQ

Monday, March 30, 2009

3-30-09

Our web folks receive HTML emails from clients that do not render properly in Outlook 2007. This is a known issue & there is a work around.


(Background from the internet)

Microsoft Office Outlook 2007 uses the HTML parsing and rendering engine from Microsoft Office Word 2007 to display HTML message bodies. The same HTML and cascading style sheets (CSS) support available in Word 2007 is available in Outlook 2007.


The limitations imposed by Word 2007 are described in detail in the article, but here are a few highlights:


no support for background images (HTML or CSS)
no support for forms
no support for Flash, or other plugins
no support for CSS floats
no support for replacing bullets with images in unordered lists
no support for CSS positioning
no support for animated GIFs


In short, unless your HTML emails are very, very simple, you’re going to run into problems with Outlook 2007, and in most cases the only solution to those problems will be to reduce the complexity of your HTML email design to accommodate Outlook’s limited feature set.

(Solution from the internet)

Outlook 2007 does have a way to render an e-mail using the built in browser (security-zone).
The method is:
1) Open the E-mail in it’s own window (double click)
2) Click the toolbar button called “Other actions” in the ribbon
3) Choose “View in browser”

source:
http://www.sitepoint.com/blogs/2007/01/10/microsoft-breaks-html-email-rendering-in-outlook/

Wednesday, March 18, 2009

3-18-09

After upgrading machines to Microsoft Office 2007, we were not able to create new email profiles, getting a "The connection to microsoft exchange is not available." error message. usa.net is hosting our Exchange servers, so rpc is involved. If the machine had an existing email profile, it would continue to work, but we could not create any new profiles. Microsoft Office Hotfix KB961572 turned out to be the culprit. Removing the hotfix (even without a restart) solved the issue. Re-installing the hotfix would recreate the problem.

Tuesday, March 10, 2009

3-10-09

If you also want to add the Save As PDF functionality to Office 2007, you can add that into the deployment, as well.

Download the SaveAsPDF.exe file from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f1fc413c-6d89-4f15-991b-63b07ba5f2e5

I saved it in the Updates folder of the network share with my Office 2007 install files, but you could put it on any network share.

From a machine with admin permissions to the Office 2007 Installer share, run this command:
\\ServerName\ShareName\setup /admin
This will open the Office Customization Tool.

Choose “Open an existing Setup customization file” & select the .msp file previously created for the Office installer.

Click on “Add installations and run programs”

Click “Add”

Enter the network path to the folder with the SaveAsPDF.exe file in it, e.g. file://servername/ShareName/Updates/saveaspdf.exe

In the “Arguments:” field, enter /quiet

Confirm that “Run this program after the Office product has been installed. (Recommended)” is selected.

Click OK.

Save the setup file & close the OCT.

Now when you run the setup program on successive target machines (using \\ServerName\ShareName\setup) , it will install Office 2007 and all of its updates, and the Save As PDF add-in, too.

Monday, March 9, 2009

3-9-09

I have successfully deployed Office 2007 on several machines using the following steps:

Copy the Microsoft Office 2007 Installer files to a network share.

From a machine with admin permissions to the share, run this command:
\\servername\ShareName\setup /admin

This will open the Office Customization Tool.

Choose "Create a new Setup customization file for the following product"
Product: Microsoft Office Standard 2007 (or whatever version of Office you are installing)

Configure the Office Customization Tool with your preferences.

Save your preferences (a .msp file) in the \\servername\ShareName\Updates folder.

Microsoft recommends using a file name that starts with something like 1_ to make sure this file will always be the first file alphabetically (if you add updates to the Updates folder).

If you are installing a customization patch in conjunction with Office updates, you should change the file name of the customization patch to ensure that it is installed first. For example, change Custom.MSP to 1_Custom.MSP.

On a target machine, run this command:
\\Servername\ShareName\setup

Office 2007 will be installed on the target machine (if you left the default uninstall preferences in the OCT, the previous version of Office is uninstalled first).


If you want to go 1 step further & install Office 2007 with its updates & patches, you can also do the following:

After Office 2007 is installed, use Microsoft Updates or WSUS to install all of the current updates & patches to the Office 2007 suite on the target machine.

Go to the Event log on the target machine and look in the Applications log for all Windows Updates messages. Note the KB number of each Office related update and go to www.microsoft.com/downloads and search for each KB number.

Download each update installer and then run each installer with this command:
Path\InstallerName /extract:Path
(Full instructions for this are here: http://technet.microsoft.com/en-us/library/cc178995.aspx - look for the section called Updates Folder)

That will create (extract) .msp files for each Office update installer.

Place all the update installers & all of the .msp files in the Updates folder of the network share.

Now when you run the setup program on successive target machines (using \\servername\ShareName\setup) , it will install Office 2007 and all of its updates at the same time.

I'm finding this to take about a half hour per machine.

Saturday, March 7, 2009

3-6-09

Due to the added security restrictions of Windows Server 2003, if you want to run an application on a network share or mapped drive, that machine must first be added to the Intranet Zone in IE.

Monday, February 23, 2009

2-23-09

After install Microsoft Windows Server 2003 Service Pack 2 (SP2) on your computer, you run processes that use performance counters. In this scenario, the following Warning event is logged in the Application log:

Event Source: PerflibEvent Type: WarningEvent ID: 2003Description: The configuration information of the performance library "C:\WINDOWS\system32\perfts.dll" for the "TermService" service does not match the trusted performance library information stored in the registry. The functions in this library will not be treated as trusted.

CAUSE
This problem occurs because the size and the date of the Perfts.dll file in Windows Server 2003 SP2 do not match the size and the date that were stored earlier in the registry for the Perfts.dll file .

RESOLUTION
To resolve this problem, follow these steps after you install Windows Server 2003 SP2:
Click Start, click Run, type cmd, and then click OK.

At the command prompt, type the following command, and then press ENTER.
lodctr /T:TermService

Note:
This command will modify the size and the date that are stored in the registry for the Perfts.dll file.

Type exit, and then press ENTER to close the Command Prompt window.

from:
http://support.microsoft.com/kb/932813

Friday, February 13, 2009

2-13-09

When doing a MAC Address lookup (search) for the vendor of 00D0CC - the result is technologies lyre inc. or Lyr-Tech, a company out of Quebec, Canada that I can't find much info about on the internet.

For us, those MAC addresses are the network adapters of our Neural Networks Multimerge/Loudness Control boxes.