Moving the Windows task bar between displays

At work, i have a rather nice 24" Samsung display as my main viewer, to the left of which stands my laptop. Since i do some full screen remote desktop work from time to time, i decided that maybe it's better to have the task bar on the laptop screen even if it's father from my focus and my pointer (see Fitt's law).

There are three ways you could move the task bar to the Other display.

The way that does not work - Right click the task bar and choose Properties. Click and ogle foolishly. While you can choose where on the display the Task bar will reside, there is no way to instruct Windows on which display to put it.

The cumbersome way - The really nonintuitive way would be to right-click the desktop, choose Screen Resolution (no, not Personalize, though you can get to the Screen Resolution display by clicking the Display link on the Personalization page :). Then click the relevant display and tick Make this my main display. Click OK.

The direct interaction way - Right-click your task bar and uncheck Lock the taskbar (it probably is, and should be checked). Drag it to the other display. Right-click it again and Lock the task bar. Nifty, though as a side effect, this will make your display with the task bar your main display. Not that i know what that means, but that's how the cards roll.

Extreme basketball

Test upload

Email address policy firstname@domain with Exchange and PowerShell

If you don't know of Exchange (2010) E-mail Address policies, you should. If all your company's people should have an address firstname.lastname@somedomain.com and a secondary address firstname.lastname@somedomain.net and then suddenly a new address firstname@somedomain.com -- you need E-Mail Address Policies.

Not only that, but you also need PowerShell, since the Exchange console Email Address Policy editor does not support arbitrary email address templates. One address template it can't handle is just that, firstname@anywhere, for which you need Powershell.

Fire up your Exchange Management Shell and enter something along this line:

Set-EmailAddressPolicy -Identity 'Default Policy' -EnabledPrimaryAddressTemplate "smtp:%g.%s@somedomain.com" -EnabledEmailAddressTemplates "smtp:%g.%s@somedomain.net", "smtp:%g@somedomain.com"

That last bit was the magic one. Substitute the 'Default Policy' to whatever policy you're editing and the somedomain.com to suite your organization.

The spontaneously disappearing printer

In retrospect, it's all very obvious, like most things technical are. I got a case from a customer's site saying that every once in a while, they became unable to print anything and they needed to restart the printer to get output on paper. Needless to say, they were pretty annoyed about the situation. But with that information, it could have been pretty much anything. 

I called the site and asked for some details. The site in question is a small store with just a few computers and two printers. They said the problematic printer was a Brother and they use it from all the computers in the shop. I took a remote connection to their site and found through some iteration the computer providing the print queue. The shared printer turned out to be a network printer (as indicated by the Ports thing on the printer queue) so i did three things: 

1. i started digging through any Windows event logs for errors (but couldn't find any),
2. i had a look at the web UI of the printer, and
3. i started a continuous stream of pings (ping -t) to the printer

There was one thing i didn't realize to do which i'll tell you in a while.

The UI was horrible to look at and had a copyright 2006 text on it. The network configuration (and other "dangerous") bits were protected by a password.

Suddenly the printer's web UI became unavailable. I looked at the ping thing but the address kept on answering. I thought that maybe the printer had faulty firmware and a flash would be in order. There was however something strange with the pings. The TTL value had suddenly changed. I checked out the ARP tables (arp -g) for the printer, flushed the ARP tables, and checked again. This could only mean one thing. There were two devices on the network with the same IP address.

The thing i had left out earlier was to check the ARP tables before i started pinging. I would then have had a MAC address for the printer as it still was available.

I called the store and asked them what networked stuff they really had there. It turned out that their credit card reader is on the LAN as well. A-ha! So keeping the ping -t up, i asked them to power off the printer -- the pings stayed up -- then unplug the credit card reader. Plop. Connections time out. Ask to power up printer. Ping response. Flush and check ARP table. And indeed, i now had two MAC addresses for that IP address. Plug in credit card terminal. TTL changes. Flush and check ARP. And the MAC address has changed. 

Target acquired. Cause confirmed.

Since i had no access to the credit card terminal, the only solution would be to change the IP address of the printer. Ping to find an unused address on the LAN. Google for the standard password of said printer (and sigh with relief that it was valid). Change the IP address of the printer. Change the IP address for the print queue's Port. Test print from all computers. Phew. Mission accomplished.

So what can be learned here? Static IP addresses are bad. DHCP is good. And documenting your network is even better. Had the TTL value not changed when the pings started to go to the credit card terminal, the debugging would have taken even longer.

Needless to say, the shop's boss was very happy (and i hope he mentions it to my boss :). On Monday i shall have a look at another similar store where they have a spontaneously disappearing server...