Microsoft

One behavior change that isn't well known to most people using Outlook and Exchange is that when you turn on cached mode on the Outlook client, your address book reverts to the Offline Address Book that is generated by Exchange/Outlook. By default the OAB is updated every 24 hours since the last time it was accessed.

Typically, that doesn't cause a lot of problems except when a new user is added or deleted from the GAL and all the cached Outlook clients still see the entries or don't see the entries that are now invalid, yet people running non-cached are perfectly fine. A lot of times you end up thinking that the RUS service hasn't done its job but it really has.

If you want your cached users to allows 'ping' to the live GAL instead of using the offline address book, use this registry key:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Cached Mode
Parameter: DownloadOAB
Type: REG_DWORD
Value: 0x00000000

One thing worth noting: If users go offline with this registry setting, they won't have a GAL to refer to anymore, so it is almost better to setup the OAB to update more often if your Active Directory isn't huge.

More background information on OAB can be found here:
http://support.microsoft.com/kb/841273

Taken from the release notes:

[snip]

To grant access to a user whose Microsoft Office Outlook is configured for cached mode, but to deny access otherwise:

The ProtocolSettings attribute on the user object in Active Directory stores client access settings.

This attribute is a multiple-valued string property, where each string applies to a different protocol. MAPI access can be restricted by manually adding the following string to the ProtocolSettings attribute using a tool such as ADSIEdit:

MAPI§§§§§§§§

The eight § separators define exactly nine fields. The fields have the following meanings.

MAPI
Specifies that this string contains settings that apply to the MAPI protocol


0 to block all MAPI access; 1 to determine MAPI access based on Bool2


0 for no effect; 1 to deny access to non-cached mode Outlook clients

Remaining 6 fields
Currently not used

If there is no MAPI string in ProtocolSettings, all MAPI clients are allowed.

Note:

The access restrictions specified earlier do not apply in the following cases:
The client is an Exchange component (for example, the mailbox moves work correctly regardless of the MAPI access settings for the mailboxes) or the client is doing delegate access to the mailbox.

If the MAPI string does not have the eight separators and conforms to the expected data types, the behavior is undefined. The ProtocolSettings attribute is cached in the MBICache and in DSAccess, and these caches may delay the time that is required for a change in the ProtocolSettings to become effective.

[/snip]

Unfortunately, it doesn't handle the situation very "nicely". It will simply deny access to anyone trying to connect in with a non-cached connection.

Many thanks to anonymous commenter, "JC", for the tip on where to find this.

I think this falls under the 'unsupported' umbrella by Microsoft but it is nice to know that it is at least doable for installations that don't need/want MSDE and would rather use the 'real' SQL for their WSS sites. I do believe you might be able to trick WSS into using SQL 2005 Express with WSS 2.0 SP2 but I could be wrong on it. I haven't tried it out personally but would be curious if anyone has had any luck with it.

Link on the details:
http://weblogs.asp.net/jan/archive/2004/02/03/66544.aspx

I've seen this on a few Exchange servers now and it is a bit strange. Something tells me that either the setup program doesn't check the right spots, or possibly some post-SP1 hotfixes register a few IMF registry entries when they really shouldn't.

I haven't narrowed down the reasons why, since it is easy to just install the old IMF for real, then go right back into Add/Remove Programs and remove IMF for good. That seems to make the SP2 setup installer happy.

Very strange. I'm sure someone somewhere knows why, and if I had time, I'd run the setup program thru regmon to see which keys it is querying.

This is just plain neat and clever. I found it at: http://terminal.servebeer.com/php/reset_winstations.php

For /f "tokens=2" %i in ('QWinSta ^| Find /i "listen"') Do Echo y | RWinSta %i

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 made me crack up for some reason today.
Unintended insults, from autogenerated code.

[snip]

'------------------------------------------------------------------------------
'
' This code was generated by a tool.

[/snip]

HEY!
That's not very nice to call someone.

I understand the reasoning, but I'm curious how it is going to pan out for organizations that are typically cheap on hardware. I love pushing 64-bit in general, so it is a good idea, but I'm curious if a lot of places are going to stick with Exchange 2003.

I guess we'll see how saturated the market is with 64-bit servers by the time Exchange 12 ships.
It seems like at least having the 32-bit version available would be a good idea.

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 do feel like I'm in airplane and I can't pop my ear pressure correctly, which results in impaired hearing, plus the stuff coming out of my sinuses could be used in a Ghostbuster movie, very easily.

Anyway:

One aspect that is glossed over in the installation guide for Office Project Server 2003 is that by default (at least when I installed it on our server), it does not populate the user tables with accounts from Active Directory automagically.

Normally that wouldn't be a problem, but I was thinking that it wanted my AD account information when I was going to the Web Access portal. Nope. It was looking for the username 'Administrator' with whatever password you assigned it on install.

On our domain, Administrator doesn't really exist (the SID does - but the actual name is renamed - security thru obscurity - I know, I know) so it was of course the last thing I tried.

So, save yourself some time and learn from my mistake - don't assume it is looking for AD credentials when you try to log into the Project Server. The error message was unfortunately not much help. It told me to ask the system administrator for help. Well, I can ask myself all I want, I still didn't know.