hosebeast

There are actually multiple problems with Intel's NIC drivers, not just the 4K problem described in MS KB 923831. Historically, the big killer has been the problem with the manufacturer header. This is actually due to Microsoft's bug in the Windows 2000 RIS parser but it means that any NIC driver which needs to support both Windows 2000 and XP/2003 must include an extra section in the INF and Intel seldom bothered to get this right because it only matters when using RIS and the vast majority of the planet doesn't use RIS. Intel's original "solution" was to provide a separate, hard-to-find download for a RIS-specific INF: http://downloadcenter.intel.com/Detail_Des...44〈=eng They explained this separate download in an equally obscure and badly written article: http://support.intel.com/support/network/sb/cs-000023.htm This download was just an INF file; you still needed to download the regular driver, then replace the INF. Sounds great until you realized that Intel never updated the INF download to match the latest driver version. Even if you wanted to run a 4+ year old driver version, Intel openly admits that it would be downright dangerous: http://security-center.intel.com/advisory....anguageid=en-fr Fortunately, most of the newest Intel driver downloads include a RIS-compatible INF. Intel claims that this includes all versions released since 2006 but I believe they still screwed up on one or two releases. It's actually fairly easy to fix one of their bad INF files; simply open it in Notepad and change the line: [intel.NTx86] to [intel] If that's all you do, you wind up with an INF that can be used with RIS successfully but not with non-RIS installations. Intel's newer versions can handle both RIS and non-RIS with a single INF by repeating the entire contents of the section under both headings [intel] and [intel.NTx86]. Obviously, this bloats the INF and makes installation take slightly longer. This section doesn't impact the 4K limit described by KB 923831; that's a separate issue which only affects the "data" portion of the INF where localized strings are defined. In fairness to Intel, other manufacturers like Broadcom have been struck by the same issue: http://www.broadcom.com/support/ethernet_n..._drivers.php#79 Notice that the fix for their INF is slightly different (changing the entry in the [Manufacturer] section which points to the headers below it, rather than changing the headers themselves) but it's essentially the same workaround for the same RIS parser issue.

I have reported this to Microsoft but no telling when/if they will correct the KB article. This hotfix from November 2005 appears to have been left out of SP3, even though it was obviously intended to be included. After applying SP3 to RTM, you will find that Otkloadr.dll has not been updated. You can then apply KB907417 and it will apply successfully. After that, you will find that Otkloadr.dll has been updated. If you extract the CAB inside the MSP and look for Otkloadr.dll inside it, it doesn't exist at all. I have only checked the U.S. English version; I don't know if other languages are also affected.

Yes, it works great but notice that it was signed on Sep 11, which means Microsoft knew about the problem for over 3 weeks and is just now making the fixed download available. Also, they are "quietly" re-releasing it (without v2 in the filename or any indication on the download page). Would it kill them to make an effort?

Desktop Outlook (i.e. Outlook 2007, 2003, 2002, 2000, etc) does not use Outlook Web Access nor ActiveSync to communicate with Exchange Server. It can use either: MAPI RPC - if your Outlook client is on a LAN, WAN, or VPN with the Exchange Server (in other words, nothing is blocking or filtering traffic) RPC over HTTPS - if you need to connect over the Internet without a VPN and still be able to use full Exchange-Outlook functionality IMAP (with or without SSL) - next best to RPC over HTTPS for connecting over the Internet without a VPN because it comes close to normal Exchange-Outlook functionality but the server-side configuration is much easier than RPC over HTTPS (which tends to baffle some "9 to 5" corporate admins); biggest drawback with IMAP is that you can't access the full information for Contacts and Calendar appointments in your Exchange mailbox POP3 (with or without SSL) - worst choice because no special Exchange-Outlook features are accessible via POP3, but this option is favored by some colleges due to ease of support when a large percentage of the user base (students) changes every few months Outlook 2007 has a new wizard for account setup which attempts to automagically detect the most appropriate way to connect to your server based on your email address. In the real world, however, there are too many domains and servers which have been set up by their administrators in quirky ways which confuse the wizard. Best bet is to configure the account manually using info from your server admins. Some organizations choose to use OWA as their only method of external access to Exchange. In that case, you would simply not be able to use Outlook 2007 outside your company's network. There are Mac and Linux email programs which communicate with Exchange thru OWA by "scraping" web pages but that's unreliable and slow.

No, the only thing you can "see" in the Outlook user interface are "Blocked Senders" (your personal blacklist), "Safe Senders" (your personal whitelist), and "Rules" (your personal keywords and other custom criteria). The Microsoft filter data is not visible. You can check the version of your filter by looking at 2 files under Program Files\Microsoft Office\OFFICE11: OUTLFLTR.DAT for Outlook 2003 U.S. English is currently version 1.4.5618.83 for the September 2007 release (digitally signed August 22, 2007). This file contains modified MD5 hash values for over 100,000 key words and some corresponding weight criteria for each word (whether it is used in subject or body, what day of week was the message sent on, etc). Microsoft uses an automated process to generate these word lists based primarily on the most common spam messages hitting Hotmail lately (over 60 billion messages per month if you count all languages). In essence, it's a Bayesian filter which is being "trained" monthly by hundreds of millions of people worldwide. OUTLFLTR.DLL for Outlook 2003 U.S. English is currently version 1.4.3504.0 and has not changed since SP1 (digitally signed November 4, 2005). Since the actual words are not stored in the DAT file, it is not possible to view them in any way. However, since most (not all) of the words are regular English words which can be found in a dictionary, brute force can be used on the hash values to determine the majority of them. Serious spammers undoubtedly go to that trouble, but otherwise the list is long and boring, changes monthly, and cannot be altered without corrupting the digital signature.

Wrong thread. I have answered that issue in this thread.

Looks like it's a bug in the September MSP. If you go back to KB936643 from August, it will slipstream into SP3 fine. You can then add the MSP from September to your slipstream and edit the setup.ini file (located under files\setup below your slipstream base directory) so that it will automatically apply the September update at the end of setup. Here is an example of what you would add to setup.ini: [ChainedInstall_1] TASKTYPE=exe PATH=c:\windows\system32\msiexec.exe CmdLine=/p c:\o2k3sp3\outlfltr.msp /qb Of course you will need to adjust the paths in this example. Also, if you already have a ChainedInstall_1 section, change the suffix number to the next available. Hopefully Microsoft will fix the bug in the October update. Until then, the only alternative to the chained install workaround would require manually replacing the outlfltr.dat and outlfltr.dll files (under files\pfiles\msoffice\office11) and then editing the msi file using something like Orca to update the Version and FileSize columns on those two files in the Files table.

Something to keep in mind: by default, 2000/XP clients installed from RIS will have value(s) in the following registry key pointing to the RIS share: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup If the client needs to Add/Remove Windows Components in the future, it will look to that share, which obviously won't work if you don't plan to leave your laptop forever. There are several possible ways you could address this, but probably the easiest is to include a [Components] section in your SIF which installs everything those clients are likely to ever need.

This is a known and documented issue. It occurs because you are using ImageType=Flat and having PE show up in the regular list of images like an installable OS. To fix the problem: 1. Create a Tools folder in your RIS folder structure. It goes at the same level as your Images folder. For example, if your images are stored below \RemoteInstall\Setup\English\Images then you would create \RemoteInstall\Setup\English\Tools. Your actual PE files can stay below Images; you don't need to move them under Tools, but the Tools folder must exist. 2. Modify your Default Domain Policy GPO to enable the Tools menu. This setting is located under User Configuration, Windows Settings, Remote Installation Services, Choice Options. 3. In your SIF file, change ImageType=Flat to ImageType=WinPE 4. Move the Winbom.ini file from your PE's I386 folder to the root of the image (in other words, move it up one level). 5. Restart the Remote Installation service for it to see these changes. Now when you boot to RIS, you will find PE in the Maintenance & Troubleshooting menu. Note that this procedure only works if your RIS server is Windows Server 2003. It does not work with a Windows 2000 RIS server, even if you have all the RIS updates for 2000.

The MSDN media issue only exists with the multiboot CD-ROM. The ISO images available on the Subscriber Download site are separate (not multiboot) so they don't have a problem with RIS. Also, if you chose the DVD option for your subscription, you receive both a multiboot DVD and a separate DVD which contains ISO images you can burn of CDs which are RIS-compatible.

If you do not have a Volume License for XP, you cannot use UnattendMode=FullUnattended in your SIF file. You must omit ProductKey from the SIF file and specify either DefaultHide, GuiAttended, or ProvideDefault for UnattendMode. This means that each machine will stop and wait for a product key to be entered when it gets to that point. Also, your OEM must supply a product key which can be activated. Large OEMs (known as SLP) may ship COA stickers with dummy product keys that cannot be activated; you must use their "recovery CD" to reinstall pre-activated. An OEM licensed copy of Windows XP is not the same as a retail license. An OEM license does not give you the legal right to reinstall (via RIS, Ghost, FPP CD-ROM, or any other means) Windows XP unless you separately obtain an "upgrade" license via Volume, Retail, or other non-OEM channel. For most typical organizations, this essentially means that they must purchase a Volume License on top of the OEM preloaded copy which comes with new machines, in order to be able to re-image the machines legally. Don't try to tell me this sucks. I'm just telling you what the license terms are. I didn't say I like them.

Don't assume that the 300-400 MILLION Windows XP users worldwide are ALL computer literate enough to know what a "crack" is. There are people running pre-SP1 because they've never heard the phrase "Service Pack" in their entire lives. The world of MSFN readers is a pretty tiny portion of Microsoft's market. There's a woman I work with who has been using XP for 2 years and has a college degree, but she still can't remember how to reboot without someone talking her through it. I don't like WGA either, but it's definitely going to make at least tens of thousands of the "casual" pirates go legit. These are the people who got a stolen VLK "from a friend of a friend" and couldn't find anything on the Internet on their own unless it's linked from their AOL home page.

No, there is no policy available for this, but you can deploy a Startup Script via GPO which will accomplish it. Startup Scripts are set under Computer Configuration, Windows Settings, Scripts (Startup/Shutdown), Startup. These run in the context of the local system account before the logon dialog is displayed. In VBScript, you would use something like: On Error Resume Next Set oShell = CreateObject("WScript.Shell") oShell.RegWrite "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName", "YOURDOMAIN", "REG_SZ" oShell.RegWrite "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AltDefaultDomainName", "YOURDOMAIN", "REG_SZ" If you have disabled VBScript on client computers and/or your client antivirus is configured to block all scripts without regard to actual content and/or you already have existing Startup Scripts using BAT/CMD and want to stay consistent, you could use something like: REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultDomainName /d "YOURDOMAIN" /f REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AltDefaultDomainName /d "YOURDOMAIN" /f Just don't try to run regedit and merge a reg file from a file share because network shares are not accessible at the time Startup Scripts run. Obviously, replace "YOURDOMAIN" with the name of your domain. If it doesn't match one of the domains in the drop-down list, it will be ignored. Note that this won't stop users from dropping down the list and changing it, but it will ensure that the default is set before every logon. Another thing you can do with GPO is display a message at every logon. Look under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options for the policies named: Interactive logon: Message text for users attempting to log on Interactive logon: Message title for users attempting to log on Large organizations frequently use these policies to display "Authorized users only" types of messages (because it apparently makes it easier to prosecute intruders) but you can display anything you want, such as "If your password is rejected, please make sure you are logging on to YOURDOMAIN and not NEWDOMAIN."

It? What is "it"? ISA 2000? ISA 2000 SP1? ISA 2000 FP1? ISA 2004? ISA 2004 SP1? ISA 2004 SP2? Your problems are going to stay unsolved for a long time if you can't get used to being specific. And those would be? Again, you're not going to get anywhere if you can't be specific. Perhaps the Cingular 8125? If so, have you updated your firmware yet? Check it by going to Start, Settings, System tab, Device Information. You should see: ROM version: 2.25.11.1 WWE ROM date: 05/11/06 Radio version: 02.25.11 Protocol version: 4.1.13.12 ExtROM version: 2.25.11.102 And that would be with PSK or certificates? With the built-in VPN client or Bluefire or NetMotion? Test with Bluefire before you decide that the problem is ISA; it's far more likely that you're running into the many bugs in the WM5 VPN client. The VPN client in WM 2003 had fewer features but was more stable. The fact that you can connect consistently to a Cisco box doesn't necessarily mean that the client is reliable, just that its bugs may be less sensitive to a particular PIX or IOS firmware build than to whatever version of ISA you're running. IPSEC implementations can be extremely finicky.

You're still running ISA Server 2000 on Windows 2000 Server, aren't you? ISA 2004 on WS 2003 handles VPNs great. The product was almost entirely overhauled, and the management UI makes it much easier to get configuration right, and you can download the ISA 2004 BPA (Best Practices Analyzer) to check everything. ISA 2006 will be shipping soon. The big problem with your wishlist is the content filtering. Nobody provides true content filtering in a standalone product for cheap. All the free/cheap choices which claim to offer content filtering are ridiculously primitive. If you have a very small number of users, you could look at Sonicwall's low-end boxes. Otherwise, there's really nothing worthwhile available in your budget range. But if you go with ISA 2004, you can get free and customizable Destination Sets to do filtering: http://www.isaserver.bm/destination_sets.html Other must-know sites for ISA resources: http://www.isatools.org/ http://www.isaserver.org/