Microsoft has created a rather nifty option to share resources in a server-less environment (eg a "home" or just a small office), called HomeGroup sharing. It works in Windows 7 and somehow magically builds on IPv6.

But HomeGroup sharing isn't available on XP, so you'll have to take the traditional road of right-clicking the folder you want to share, choosing Advanced sharing and setting the security bits just right (eg Share security: write for Everybody, full control for Administrators; File security: as tight as you need).

But sometimes that's not enough.

At a client with a mixed machine environment, suddenly they couldn't get to a file share residing on a Windows 7 box when coming from an XP box. I got system error 58 (or was is system error 85?). Windows croaked. I tried firewall settings, tried user rights, tried whether the fact that they'd connected to another file share on another XP box.

While i did a whole bunch of seemingly arbitrary fixing moves, after doing the following, things started happening again.

• Start the local security policy editor, secpol.msc
• Go to Local Policies > Security Options
• Scroll down to Network Security: LAN Manager authentication level
• Change the setting from "Send NTLMv2 response only" to "Send LM & NTLM - use NTLMv2 session security if negotiated"

The reasoning behind this is that Windows 7 and Vista works on a newer and more secure variant of the Lan Manager protocol than XP. You might get similar problem if connecting from a Linux box or a NAS (which very well may be a Linux box) to a Windows 7. Changing this setting starts the discussion using the older version and switches to the more secure one if the two endpoints can agree on that.

Took me several hours to get this right. I hope this will help you make a swifter fix.

We have one unreliable virtual server which sometimes just loses its network connection. Until we have a permanent solution, the temporary fix is to have the computer reboot if it loses network connection.

Note: There is nothing as permanent as a temporary solution. With that warning, let's get to it.

Step 1 - Produce the following Powershell script into c:\bin\pingdog.ps1

$netup = new-object Test-Connection -quiet "goo.gl"
if( $netup -eq $False ) {
  Restart-Computer
}

Step 2 - Fix your security settings

Start Powershell. Enter Set-ExecutionPolicy RemoteSigned or whatever level you're comfortable with that'll still run your script.

Step 3 - Schedule it

If you're using Windows Server 2003 (like we, ungh) schedule a daily task to run %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe c:\bin\pingdog.ps1

From the task's Properties, the Schedule tab, press the Advanced button. Tick Repeat Task, every 12 minutes (or whatever you fancy), and repeat for 24 hours.

If you're using Windows Server 2008 or later, you should be able to set the task to run evey x minutes right from the interface.

Step 4 - Check your logs

Keep an eye on the failing computer's system log to see if it's restarted when you looked away.

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...

The takeaway: Uncheck "user must change password on first login" to access Outlook Web Access.

A customer of ours had a very typical request. They would need "a user called info" to handle mails to info-at-their-domain. They would also be hiring an external person to handle the surge of Info activity they were planning for, using Outlook Web Access. Their infrastructure is Microsoft Small Business Server 2008 with the bundled Exchange 2007.

Step one in any such project-let is not to mistake customers' wants from customers' needs. What they needed was an info mailbox which given users on the inside could read from their own accounts, and a separate account for the external person, who'd have no mailbox of her own but would be allowed to access that same info box.

First things second, create the user. Usually externals would go go a separate Organizational Unit in Active Directory, but since this is a Small Business Server, things just tend to work better (or at all) if mucked about the wrong way. Thus, no extra OU. Just create a user x-username (to at least visually mark that the user is an external) and then peel off extra rights like interactive login or access to shared files. 

To create a shared mailbox, you need to use the PowerShell Exchange management console. This process is described elsewhere and i need to google it each time too. The same document will tell you the next two steps needed to allow x-username to read mail from the box and to send mail in the name of the box. I tried doing this using groups, but at least one of the steps failed. It wasn't very clear either which of the options are for the user and which for the mailbox, but in the end i got it to work. Or so i thought.

I sent the external user her credentials and URL to access the shared mailbox directly (which was news to me - https://mail.example.com/owa/info@example.com will take you there). And soon got a reply that there was a problem.

A few back-and-forths later and it turned out that she was unable to log in to OWA. I reset her password, but the problems prevailed.

After some debugging, i tried to uncheck the option in Active Directory Users and Computers where it says that the user must change her password upon first login. This is on by default, and it is a good default. Hey, presto! The account was good, i could log on with the external's credentials and was taken directly to the info mailbox.

What failage. OWA could allow the user to change the initial password. Or could inform that the password needs to be changed first on a proper Windows session. But not like this.

Well, at least i have the user on line now, doing her work, and myself another blog posting.

Your job: Install a new computer for a client and transfer all the documents. The old box is a Windows XP, the new one runs Windows 7.

The tool: Windows File and Settings Transfer Wizard.

The caveats: Many.

It's a well known story. Your client has a new computer to install. She's used the old one for quite a while and it's full of documents (in weird places), although you've suggested storing them on the server, "just in case". But old habits die hard.

Thankfully, Microsoft has a pretty good tool for this case, namely the Files and Settings Transfer Wizard. This baby does most of what you'd believe it show and it's been bundled with Windows since the XP times. 

Step one: get an external hard disk or a fairly large USB flash fob (thumb drive, "minnepinne"). While you could do this over the net, it's probably faster over the USB. Nothing will be deleted from the external device so don't worry about that bit. 

Step two: Start the process from the new computer. Plug in the external memory device and fire up the F&STW. While the old one probably has the equivalent software installed, the file format has most likely changed between your brand spanking Win7 and the old XP box. This was learned The Traditional Way.

You do not need to be logged in as the user whose data is to be transferred but you will need admin rights on both the source and the target box.

Now tell the Wiz that you are on your new computer and that you haven't done the transferring bit just yet. FSTW will create an installer on the external disk, after which it'll close (given a button-push or two). 

Step three: Eject the external disk and plug it into the old computer. Run the installer created above. Start it and press the appropriate Next buttons. The transfer will commence. Have tea, this'll take a while.

Step four: Again, eject the external hard disk, plug it into the new computer. Navigate to where you created the transfer files (which probably is where you left the installer a few steps back) and open up the .MIG file there. This will awaken the FSTW anew, to let you drop the files and settings on the target computer.

Let it churn. Have more tea.

Step five: Check trough the transfer logs. Save the log for transferred files. Resist the urge to check trough the list of applications missing, and even more so, resist the urge to install the missing programs on the target machine. This, too was learned The Traditional Way.

Reboot the target computer. This will not be evident until you continue stepping through the logs. This, also, was learned The Traditional Way.

Step six: Surprise surprise, FSTW has not transferred the Outlook .PST Data Files from the source computer. Eject the external disk from the new computer, plug it into the old. Open the Control Panel from the old computer, open the Mail applet, check which Data Files are in use, click each one and the button to show the actual folder in which the .pst file is in. Outlook must not be running while doing this. Exit it, completely. Old Outlooks will leave a thread hanging to check for new mail.

Manually copy the .pst files to the external medium. Eject disk. Plug it into new computer. Create a directory c:\Users\%username%\Outlook and manually copy the .pst files from the external disk into it.

Only now, start Outlook on the new computer.

At this stage, i have no idea if Outlook will have its settings transferred or incorporate the .pst files on the previous computer, as this too was learned The Traditional Way (or more so, Obscured in The Traditional Way) so you're on your own here. The only thing to add is that you can use the Mail applet from the Control Panel to add the .pst files to the new account if they aren't there from before.

Apart from that, Good Luck. You're a sysadmin, and you need it.

I discovered a painfully simple (and only slightly inelegant) way of deploying software in a Windows Active Directory environment, namely Zap files. While you'd usually want to deploy an .msi file, you use Zap files when you want to deploy an .exe file.

Big fat caveat -- The installation will run on the user's rights, so s/he must have software installation privileges on the computer s/he's running, or the installer must have admin credentials baked in somehow. On a secure network, you don't let your users install stuff on their computers.

And with that said, here's how to do it. Windows Server 2008 recommended.

1. Create a file share if you don't already have one. Use Share and Storage Management from Administrative tools or Server management to do it The Right Way [0]. To be Really Swanky, use DFS to publish the share on a domain scope instead of on server scope. In this example, i'll be more ghetto and shall call the share \\fileserver\Install and i shall call the fictional package to install agent.exe

2. Put your agent.exe file somewhere within the share created above; for the sake of this example, in \\fileserver\Install\agent.exe

3. Create a text file agent.zap (you can create it as agent.txt and rename it to dot-zap later) and place it in another share, or the same if you don't believe in security by obscurity, or don't have a compulsive manner in keeping things in neat little boxes. Here's what you'll put in the agent.zap file

[Application]
FriendlyName = "The Agent"
SetupCommand = "\\Fileserver\Install\agent.exe /any /switches"

Wikipedia tells me there are loads of other commands, but this will do for the Ghetto Installation we're doing now. Anyway, the [Application] row must be written like that, in verbatim. The next row is what's going to be shown to the users when they want to install the file. And the SetupCommand shall point to the UNC path where the installer resides. Any command switches can be put after the executable name within.

4. Open Group Policy editor. Browse to your users' folder (or where-ever you want to apply the deployment). As i'm on Small Business Server, that would be around ...\My Business\Users. YMMV. Right-click to Create a GPO in this domain and link it here. Call it Published Software (since eventually you'll put more published software here).

5. Under User Configuration / Policies / Software Settings / Software Installation, right-click New / Package. Navigate to where your .zap file is, make sure the file type selector is .ZAP (and learn that .zap stands for ZAW down-level Application Package) and select it. Click OK. Select Published to force the installer down your users' throats(generally a bad call) or Advanced to modify the settings and under the Advanced tab on the next dialog box, unselect Auto-install this application not to force feed the app.

6. Showtime. Log on as a user on a workstation. Open Control Panel. If you're on Win7, find the option "Get Software". If you're on an earlier incarnation of the ubiquitous desktop operating environment, go Add/Remove Programs or the like and choose Install published software. You should now see The Agent listed there! Yay presto!

And that's about the size of it on a space like this. Experiment and write about your experiences in the comments below!

How do you map a network drive using Group Policy? You use Group Policy Preferences. No script required.

I got a pretty typical request from a client today. He'd hired a new employee, for whom i'd installed a computer a few days ago. One thing i hadn't done was to map to a network drive. Typical task, typical setting. I don't know why she (the new hire) didn't have the drive mapped but i promised him (my client) i'd fix it tonight. Which i did.

There are two ways to map a network drive:

1. the Stupid way, which is to log in on a computer as the user and map the network drive and set it to re-map between sessions (/persistent:yes)
2. the Ordinary way, which is to have a logon script run from the logon server, mandated by group policy.

There is also a New way offered on Windows Server 2008: Group Policy Preferences. Unlike Group Policy Settings, preferences are something that are suggested rather than mandated to the user, who may change the suggested preferences if so wanted. Another thing is that there are a bunch more preferences available than i'd found in GP Settings, and the one i was looking for was indeed the preference for drive maps.

For magic to happen, open the Group policy manager and create a new Group policy opject (GPO) where the users you want to target are. Call it Drive mappings. Go to User configuration -> Preferences -> Windows settings -> Drive maps. Right-click it and New -> Mapped drive. Set Action as Update (or Replace; see help file for info), fill in the UNC path (ie. \\server\sharename), give it a nifty Label and a Drive letter. And you're there. Repeat for other drive letters as necessary, creating other GPOs for other groups who have their own network drives. There's even variable substitution so you could probably map a drive for a group or a site or something equally local.

Given all this, drive letters are hopelessly outdated; it's just the fact that people are so used to them that it'll take a while for them to die out. And the same goes for home directories on the net. The Correct Way would be to have the venerable [My] Documents folder silently residing on the server and replicated for offline use (hint: use Folder Redirection), and any shared or common folders under the Libriaries meta-folder-thingy on the new and improved Windows 7 file explorer.

But that's for another time, when i've updated all their workstations to Windows 7.

Sometimes, Windows XP loses the user's profile and goes with a temporary profile instead which is just that, temporary. Any changes made to that profile -- like Outlook settings -- are lost with the next logout.

Here is a simple ten step process to get the profile back.

0. Reboot the computer. You'll see why in a minute.

1. Log in with Administrative priveleges (domain or local). If you're trying to recover your own profile and your own logon has admin priveleges, you need to take the longer route. You need to log in as somebody else than you're trying to restore. [0]

2. With Windows Explorer, navigate to C:\Documents and Settings. From View » Options » Advanced [1], set the appropriate option to show hidden files and folders.

3. Make a backup copy the Problematic user's directory under Documents and Settings -- for this discussion, we shall call it C:\Documents and Settings\Problematic or Problematic for short -- just in case. This is why you needed to reboot; if the user has been logged in since the last boot, there will be some files locked inside the Problematic directory.

4. Tricky time. Rename the hidden (and now made-visible) directory Default User into Default User Original. Rename the Problematic directory to Default User. [2]

5. Log out Administrator and ask Problematic to log in. Since Problematic does not have a profile, a new one is created using the data from Default User. This is not just magical, but doubly so, as the bad data isn't copied verbatim but used as profile fodder to create a new and altogether less Problematic user profile!

6. Log out Problematic (who know for the discussion really should be called something else :) and log in as an administrator.

7. Delete the "Problematic" Default User directory. Rename the Default User Original into Default User.

8. Log out. Feel smug.

OK, that was only nine steps so keep one in store for your next sysadmin magick. We both know you will both use and need it.