Change the READY message on HP Printers

A little bit of Friday humour...

Be aware that this may be against your organisations Acceptable Use Policy. Also be aware that people without a sense of humour may not find it funny. Don't get into trouble!




The message may be reset to the default by power cycling the printer, or re-running the script and passing "READY" as the message.

Please note, I have not tested this... yet... hehehe.

Telnet to port 9100 on the printer and enter the following: 

\e%-12345X\@PJL JOB
\@PJL RDYMSG DISPLAY="MESSAGE HERE"
\@PJL EOJ
\e%-12345X

Some funny suggestions:

“Insert Coin”,

“Insert Cheese”,

“Im Sad..”,

“Low Monkeys”,

“Feed me a cat”,

“Insert Butter & Jam”,

“Free The Ink!!”,

“My Cousin Is A Toaster”,

“Load Soy Latte”,

“Paper Tastes Funny Today”,

“Free Hugs..”,

“Toner Tastes Funny Today”,

“Press OK Button for Pacman”,

“Flower Power Mode”,

“Incoming Fax…”,

“Cheese Mode”







WCCP - Traffic Flow Diagram

I couldn't find a good generic WCCP traffic flow diagram, so I created one:

SCCM: Failed in GetCertificate(...): 0x80040281

I started seeing this error in the ccmsetup.log file on some client machines after updating to Service Pack 2 on the SCCM Server:


Failed in GetCertificate(...): 0x80040281


The SP2 installation does not automatically update the client installation files. In the SCCM console, if you navigate to:


Site Database : Site Management : Site Code - Site Name: Site Settings : Client Installation Methods


...and open Software Update Point Client Installation, you should be prompted to update the published version of the client. Note that it can take 30 seconds or so before you can re-open it to see the published version match the available version.


You may also need to update the client in other locations, such as Group Policy or the Right-Click tools.

Cheers,
Sean

IronPort WCCP Redirection and Proxy Bypass List

I came across a trap for the unwary today. It seems that the IronPort WSA products Proxy Bypass List for transparent mode redirection actually operates on sources as well as destinations.



From the Administrators Guide (note the "or from"):

You can configure the Web Security appliance so client requests to or from particular addresses bypass all processing by the Web Proxy.



Therefore, putting your internal address space in the list to prevent the caching engine from performing access checks and caching upon your intranet and other internal web content will actually prevent transparent redirection from working at all !!



Rather than do this, set up your access lists for WCCP redirection on your router or switch to prevent the requests with an internal destination from being redirected to your caching engine in the first place.



Ip access-list standard wccp-devices
Remark Only WCCP devices should be listed here
permit 10.200.10.10
permit 10.200.10.20

Ip access-list extended wccp-80
Remark Deny redirection of web traffic to internal services, then permit all http
Remark Internal Devices may be listed as deny (source) here to prevent them using transparent proxy
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
deny ip host 10.100.1.50 any
permit ip any any eq www

Ip access-list extended wccp-443
Remark Deny redirection of web traffic to internal services, then permit all https
Remark Internal Devices may be listed as deny (source) here to prevent them using transparent proxy
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
deny ip host 10.100.1.50 any
permit ip any any eq 443

ip wccp web-cache redirect-list wccp-80 group-list wccp-devices password password
ip wccp 120 redirect-list wccp-443 group-list wccp-devices password password

Interface [outbound network]
ip address 10.1.1.x
ip wccp web-cache redirect out
ip wccp 120 redirect out



Note that you can avoid the overhead associated with CEF forwarding for outbound traffic on your switches by using redirection on input traffic instead of output traffic, and this will provide faster redirection of packets, but this will often mean a much more complex configuration. If you're not approaching the performance limits of your switches and it's not going to impact VOIP call quality, it's probably going to be simpler to configure redirection on the outbound port to your firewall and measure during peak usage periods (usually lunch time for web usage) for any performance impact.



Cheers,
Sean

Move and Disable Stale Computer Accounts

I started to write a script today to relocate and disable computer accounts that have an old PwdLastSet attribute. Before I got very far, I discovered that Richard Mueller of Hilltop Lab had already done quite an effective job of scripting this very task and has made the effort to refine it a few times too.

The script can be found at http://www.rlmueller.net/Programs/MoveOldComputers.txt

I modified it a little to suit my own purposes, but his script certainly got me 90% of the way there. Thanks for saving me the effort Richard!

Cheers,
Sean

Windows Update Problem Fixup Script

I've had this script floating around for a while. I put it together based on a number of recommendations from Microsoft regarding fixing problems with Windows Update.

Note that this will fix some errors, but there are a whole swag of issues that can arise with automatic updates.

Also, as always, I take absolutely no responsibility if this causes your machine to implode (although I would love to see the photos if it does!)

@echo off

if exist %systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\tmp*.cat del /F /Q %systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\tmp*.cat

if exist %systemroot%\system32\CatRoot\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\tmp*.cat del /F /Q %systemroot%\system32\CatRoot\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\tmp*.cat

if exist %systemroot%\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\kb*.cat del /F /Q %systemroot%\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\kb*.cat

if exist %systemroot%\System32\CatRoot\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\kb*.cat del /F /Q %systemroot%\System32\CatRoot\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\kb*.cat

regsvr32 /s softpub.dll
regsvr32 /s wintrust.dll
regsvr32 /s initpki.dll
regsvr32 /s dssenh.dll
regsvr32 /s rsaenh.dll
regsvr32 /s gpkcsp.dll
regsvr32 /s sccbase.dll
regsvr32 /s slbcsp.dll
regsvr32 /s mssip32.dll
regsvr32 /s cryptdlg.dll

attrib -s -h %windir%
attrib -s -h %windir%\system32
attrib -s -h %windir%\system32\catroot2

net stop cryptsvc
ren %systemroot%\System32\Catroot2 oldcatroot2
net start cryptsvc

net stop wuauserv
rd /S /Q %windir%\SoftwareDistribution
md %windir%\SoftwareDistribution
net start wuauserv

Cheers,
Sean

Local Account Manipulation

I had a request the other day from someone who knows some of my work. He had seen my scripts for manipulating local accounts on machines but couldn't make sense of them. (This was essentially because he was only seeing half of the system.) He asked if I could explain them in my blog, so here goes...

There are many different methods for manipulating local accounts on machines. Some companies make a profit from selling software that will go and talk to all of the machines and change passwords, accounts, group memberships, etc. Surprisingly, Microsoft has not yet integrated any system for easy management of local computer accounts into their own domain management systems. (Edit: Of course Microsoft has finally done something about this and you can now use Group Policy Preferences to manage local accounts quite easily. I thoroughly recommend using Group Policy instead of the method described here!)

Anyway, one way to achieve this is to use the Group Policy system. Computers run the Computer Startup Scripts with system administrative rights (Computer Configuration / Windows Settings / Scripts / Startup.) This enables the savvy administrator to run a script that can be used to manipulate local accounts.

What about the fact that the passwords may be exposed in the script? Some administrators will suggest that you do it in VBScript and then encrypt it. This is not a good idea because it is far too easy to decrypt these files. IMHO, it is much better to let Microsofts domain security protect it for you. (I can't believe I just said that. Scary but true!)

You can place these 'scriptlets' below in your scripts folder and pass the required parameters to them from your GPO. You secure your GPO by removing Authenticated Users from having read and apply group policies rights and giving Domain Computers read and apply group policy rights. Using this method, the users cannot see the new passwords, but the computers which are running the scripts can.

There is a caveat. The computers have to be processing group policies in order to run the scripts. This may be prevented by slow link detection, the behaviour of which can be modified. It may also not be processed by computers coming into the network by remote access. A user logging into the computer by remote access can process the scripts, but a user logging into your VPN or dial-up after logging in the computer using cached credentials will not process the scripts.

IDCHPASS.BAT: Used to Change a local user identity password.

@ECHO OFF
REM USAGE: IDCHPASS username newpassword
NET USER %1 %2

IDCREATE.BAT: Used to create a local identity.
@ECHO OFF
REM USAGE: IDCREATE username password
NET USER %1 %2 /ADD

IDDELETE.BAT: Used to delete a local identity.

@ECHO OFF
REM USAGE: IDDELETE username
NET USER %1 /DELETE
IDENABLE.BAT: Used to enable or disable a local identity.

@ECHO OFF
REM USAGE: IDENABLE username YES\NO
NET USER %1 /ACTIVE:%2

IDGROUP.BAT: Used to change the group membership of a local identity, or to create or delete local groups.

@ECHO OFF
REM USAGE: IDGROUP group ADD\DELETE username
REM USERNAME IS ADDED TO OR DELETED FROM GROUP
REM USERNAME CAN BE LEFT OFF TO ADD OR DELETE GROUPS
NET LOCALGROUP %1 %3 /%2


A shoutout goes to ripvankip for giving me something to write about! ;)

Sean