Windows OS

http://www.microsoft.com/windowsmobile/downloads/activesync41.mspx

Hopefully, this version works with Windows Mobile 2005 on Axim X50v devices. I could never get 4.0 to work properly.

I've run into this a few times I believe. It tends to show up more with VPN links and when there are varying MTU values along the way, between client and server.

Setting MTU to 576 on the server fixes it for everyone but that kills large window packet performance - so this is a much better fix.

http://support.microsoft.com/kb/898060

Excellent collection of information right here:
http://www.3dvelocity.com/articles/win64compatibility/win64softlist.htmhttp://www.3dvelocity.com/articles/win64compatibility/win64softlist.htm

HP is playing catch up with Citrix and Windows 2003 SP1, but this driver will be quite handy for servers out there running Terminal Services on Windows 2000 and/or Windows 2003 RTM.

It's too bad they didn't make a driver like this around the time NT4 TSE came out. I honestly think Terminal Services would be more popular today if the printer subsystem didn't have such a black eye in terms of management and issues. Sure, it's not HP's fault, and it's not Microsoft's fault either. Parts of the printer subsystem are being used/abused by things it wasn't originally designed for.

That's why I'm hopeful the new XPS system that is coming with Vista (I believe it was/is codenamed Metro) will fix a majority of the problems.

We can learn from our mistakes. The challenge is to not reimplement them in the next revision. That's what I try to do with all my little quick and dirty programs, and life in general, to a certain extent.

Anyway, here is the link to the HP driver:

http://tinyurl.com/drnm4

HP likes to change the links on their website every week it seems, so that link might not work a few months down the road.

Strange. We have a webserver that hosts a lot of ASP.NET websites (v1.0, v1.1, and now v2.0 too) and one day this week it decided to stop launching ASP pages with access denied to the global assembly cache. I checked all the usual suspects for that sort of problem.

I also noticed Windows Updates from WSUS were failing on install, almost instantly. So, I fired up 'tail -f %windir%\WindowsUpdate.log' and watched the log as I tried to install the updates again. The very first error that kicked off was a COM error about not being able to launch/attach to the process.

So, I tried to look up the error code and it seems to relate to the DefaultAccessPermission key in the registry for Ole. Yep, good ole Ole from way back when. Anyway, I still have to double check the websites after I bounce the server and repair the dot net binaries.

If you can't seem to launch any COM processes, go to HKEY_LOCAL_MACHINE\Software\Microsoft\Ole, and delete the key "DefaultAccessPermission"

The next time an app uses COM, the key will be recreated with sane default values.
I still wish I knew what corrupted the values in the first place.

I'm sure there is a more elegant or 'proper' way to fix this, but the values in that key did not look right at all compared to other servers.

It always comes with a cost, though. The biggest one is that client side certificates cannot be used anymore, plus a few other gotchas.

It's all controlled by a DWORD key at HKEY_LOCAL_MACHINE\System\Services\HTTP\Parameters\EnableKernelSSL

0 = user-mode (default)
1 = kernel-mode

More details here: http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/http/http/kernel_mode_ssl.asp

It might be old news to some IIS wizards, but it is new to me as I bumped into it when debugging an ASP.NET 2.0 error. I keep getting 'Access denied' to the global assembly cache by ANY asp page, even though all the usual permissions on the huge list of directories it needs read access to are already set. It had been working previously and I'm not sure who or what changed anything on this webserver.

This KB article on MS's support site makes me a little nervous. If I am reading it right, if an application (or a person) somehow sticks an invalid entry into AD, you effectively stop replication until you fix it up correctly. Unfortunately, it looks like 'fixing it' isn't that easy based on what is written there.

I don't want to be an alarmist or a 'tin-foil-hat' guy, but it sounds like a potentially serious problem from 2000 machines if some sort of worm gets admin rights, sticks in a few AD entries in on a domain controller, and goes on its merry way.

You probably wouldn't notice the problem right away since it would just log a few entries everytime the system does garbage collection and/or tries to replicate AD.

http://support.microsoft.com/kb/907462

I've got a data plan through Verizon for my 'data' cell phone (Motorola V265 - non-defective) which allows me to tether the phone to my PDA or laptop at home. Currently, I don't have DSL or Cable available in the new house so I'm pretty much 'stuck' with what I have until Charter rebuilds my neighborhood for digital cable, or a wireless provider comes to town (not likely), or I bring in a T1 and start my own wireless company. I've toyed with the idea a lot.

Anyway, with that background information, with peak connections of 144kbit (basically a little bit better than a dual ISDN setup) over the 1xRTT network, I'm a bit bandwidth starved so it makes sense that if I want to share files from the office, it is going to be a little painful. Verizon is hoping to have EVDO in the Grand Rapids area soon and then I'll be able to upgrade to a 'real' EVDO PCMCIA card and get closer to 1Mbit.

You might wonder why I'm using a cell phone and not a PCMCIA card. There is a simple reason: Motorola has the best RF sensitivity of any phone/card offered that I have tried. I'm on 'the edge' of the signal where we live. Any PCMCIA card would get, at most, 1 bar of strength. With a V710 or a V265, I get at least 2 or 3 bars of strength and no drop outs. Attaching an external antenna helps quite a bit too if you want to make sure you get a solid '3 bar' signal strength.

With the original DFS in Windows 2000/2003, I wouldn't have bothered even trying to setup a nice DFS setup but with the compression and 'reworking' the DFS engine has gone through in R2, my data link makes a great test bed since the peak data rates can vary and so can the actual connection. At times, I feel like I'm on dialup again.

A lot of the data I transferred was the contents of a Sharepoint website sitting in C:\inetpub on NecroQuad and a few ISO images from MSDN, which amounted to around 300MB or so. As you can see from the results below, there was a good 30% reduction in overall data transfer.

For "fat pipes", that isn't a big deal. For a cell phone, it's a huge deal.

Not many branch offices run over a cell phone line but I know of a lot of places around Michigan that are still on ISDN or IDSL. This type of bandwidth reduction, and being able to schedule replication time windows easily, will be a driving force in my future R2 deployments for small businesses.

I've got more data I'm going to publish later, but I wanted to get this stuff 'live' before I have another hard drive failure on one of the test machines. That is always the double edged sword of older hardware - a lot of times you will get donated hardware or former production machines that can't be trusted, to use as test development machines. Free hardware is nice. Failing hardware is a bummer.

Since I joined the beta, one of the most used R2-specific feature I was using/testing out was this module. Now that I can use my "management laptop" to keep an eye on "my" datacenter/terminal servers, it's wonderful.

Case in point, we have a bunch of forests on our network and within those forests are a lot of terminal servers with various printer drivers loaded on them.

Sometimes, outside of my control, someone will load a printer driver onto a terminal server that is an older style driver (aka NT 'kernel mode' printer driver). The unfortunate thing about those drivers is that if they don't sanitize/verify the data getting passed to them, it is very easy to take down a terminal server if there is a bug in the driver. Instant blue screens are usually the result because it is running in the kernel context. This is one of the primary reasons (I believe) that these type of drivers were given a 'penalty box' GPO in Windows 2003 and totally eliminated in Longhorn.

If a system seems to be tanking with blue screens, the first thing I would always check is to see if anyone added any older style drivers. You could always browse the '2' directory under %windir%\system32\spool\drivers\w32x86 but a lot of times it would be hard to figure out what file belonged to what driver unless you went mucking around in the .inf files.

The screenshot I'm attaching shows how PMC makes that job easier. I can sort by driver version (aka usermode or kernel mode or newer) and see a list of printers that could be causing the blue screen.

Being able to do that across forests is very handy, but to a certain extent might open up a security issue. It seems by default, Windows 2000 machines let you view all this driver information without any trusts setup between forests. If I were a 'bad guy' and somehow got access to the printer spooler, I could see that a server had an older kernel mode driver and try to send it specially crafted print job that would blue screen the system.

Windows 2003 seems to have default permissions setup so you can't do that sort of cross forest 'information mining'. Perhaps a 'print server permission lockdown tool' would be handy, sort of like the IIS lockdown tool.

Anyway, that is why I really like PMC on my XP laptop and just one possible use of it for people like myself.

The best way to fix it is to apply the latest patch released today due to it being patch Tuesday but the 'knee-jerk' reaction would be to block those files, but I don't think that would cover most of the risk anyway.

http://www.microsoft.com/technet/security/Bulletin/MS05-053.mspx

I won't go into the technical details.. just another unchecked buffer in a bad spot.

If you go to Netropa's site and download the DellTouch v2.11, which doesn't seem to be on Dell's website, the desktop file handle leaks are fixed.

It has been running a few days with no problems.

"It depends" is the right answer for sure, when tuning things like that.

http://blogs.technet.com/mscom/archive/2005/11/03/413608.aspx

This doesn't necessarily give me a 'warm fuzzy' feeling about a few servers we have here.
It sounds like a race condition of some kind, or a missing semaphore/lock/etc somewhere in the NTFS IFS driver.

So, if you have tiny NTFS partitions that are almost full, on a multiple CPU server, that tend to get hammered a lot, be on the look out.

http://support.microsoft.com/kb/909360