cluberti

Note that CTRL+ALT+DEL only works on XP Pro - if you've got HOME, you're a bit SOL.

So the app that's hanging isn't running, but the regular windows processes stick around (winlogon, lsass, csrss, etc) for a time before the session tears down? By any chance did you make this application the default shell, rather than explorer.exe? If so, are you waiting at least 60 seconds from a full login (app is up and running) before trying to close it down? One last thing - what happens if you add the following reg key, then log the user off and try again? Key: HKCU\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEExpress (you don't need to put any values inside, just create the "AEExpress" key under the AutoEnrollment key).

If you add /DEBUG into the boot.ini for the Windows install you're using, does the machine "hang" at the black screen instead of reboot? If so, it's a bugcheck and you can catch it with a null-modem cable, a second machine, and a debugger. If it doesn't hang, it is likely not a bugcheck and potentially a hardware or driver issue (using /DEBUG tells the kernel to "break" (pause) when an exception that would cause a system crash occurs, and thus the machine will appear to hang rather than reboot if it does break.

While I'm never a fan of snooping like this, if the boss is running the company (and the employee contracts include monitoring clauses), it should be easily done. I prefer using GFI MailEssentials for this.

TCPView is OK, but it doesn't have any detailed information about the packets sent, and isn't a great way to track something if it opens and closes connections constantly, whereas the trace can be saved and opened and taken apart more easily and thoroughly. I like TCPView to see who's using a specific port (or range of ports), or to sometimes track long-running connections, but not for things like this. I like to watch this in a network monitor like netmon or wireshark.

This is also why most virus removal instructions include disabling system restore for the duration of the cleaning - these files can contain the virulent data in their ADS, and you won't be able to clean them easily.

Are you sure these user accounts do not have administrative rights on the machines you are able to log in this way on, or have some admin rights in the domain? The filesystem should have nothing to do with it, this is strictly a user rights issue. Consider following this article to run against a user that doesn't have this rights problem, and again when you log in with a user that does seem to have this rights problem (and if you can run this after logging on over another user, that would be even better).

Since this is an SBS server, if you completely disable the firewall on the server, do internal clients display the web page properly?

If you watch the TS connections to the machine from another session or the console via Terminal Services Manager mmc, you should be able to see which processes are still running in a session as it tears down. What else lingers in the session while you wait for it to log off?

You're installing the app after installing terminal services, and you're using the add/remove programs > Add new programs method to point to the setup file for the app, correct?

Well, another question would be, are the clients all on the same network as the SBS server, or are you hitting this over the internet? The fact that all clients have the issue but not the server would indicate some sort of server-side or network issue, but are the clients connecting to OWA from the same network?

Download netmon and install it, and start watching the packets in and out of your PC to see where they are going.

Bug Check 0xA: IRQL_NOT_LESS_OR_EQUAL The IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x0000000A. This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above. So, a driver for some hardware in the machine is causing a page fault at IRQL 2 or higher (up to 31). Unless you're using a customized install CD, I'd say you could have a bad CD, or more likely, hardware that isn't 100% 64bit compatible with the driver that Windows is trying to use for it.

Much better. I've seen that happen before when I disabled scripting in the browser - this will not be a client-side problem. What happens if you build a box from scratch (not on the domain or getting your policies applied) and visit the page?

Can you re-link that image?

Do the users have "change" permissions on the folder location? Word (and other Office apps) open files as temp (the tilde files) and only write changes when the file is saved or the auto save period elapses. If you save and close a file, the tilde file is written to the original document file, and the tilde file is deleted. If the users don't have the delete and create privs on the share, this can take forever. Also, antivirus and antispyware applications can mess with offline file locations too, so make sure those are specifically omitted from scanning.

SP4 does not include the high encryption pack, and I do not think that the post-SP4 URP does either.

Outlook 2003 and 2000 require some .dll files that are included in the OS with IE and Outlook express, and those hex error messages you are seeing indicate that there are missing .dlls or they are not registered (or both). Honestly, there's not a really easy way of doing this short of using loadersnaps and a debugger, or process monitor to see which .dll files are not found (that may take a long time too). If it's worth it to you, you can do those things, or you can use an OS that includes IE and OE in the default install, as that will guarantee things will work.

Heh - been using this thing for almost a month now, and it's a beast .

That's really, really odd. Wonder why .net would be trying to look up a SecDesc ACL on something... Have I mentioned that is odd?

A side note - that error maps to EXCEPTION_NOT_HANDLED, so it could have been anything (although it was likely a driver, no way to know for certain now). Glad you got it up and running, though.

I would suggest uninstalling the current version of .net 1.1, and reinstall with the latest .net 1.1 SP1 release (and download and save the file somewhere you won't delete it from when you do the install just to be safe, so this doesn't happen in the future).

If you install a trial version, it cannot be upgraded to a full version, it has to be reinstalled completely with the full version disc. I would suggest waiting until Jan 2nd.

I'm going to save you some trouble - I don't know why the rdp client is showing 5.1, but Windows 2000 Professional machines do NOT have terminal services capability, only 2000 Server (and only when installed from add/remove windows components). Unlike XP, 2000 doesn't have this functionality built-in (and it isn't in Professional at all).

First, make sure you have no UNC paths set in the PATH statement on any client machines. Second, make sure you aren't using the %homedrive%, %homepath%, or %homeshare% variables (those are old NT4 holdovers and can cause serious network speed issues when doing folder redirection). Last, make the following changes on all of your XP and 2000 clients: Key: HKLM\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters Value: InfoCacheLevel Type: REG_DWORD Data: 10 (hex) Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer Value: NoRemoteRecursiveEvents Type: REG_DWORD Data: 1 Key: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager Value: SafeDllSearchMode Type: REG_DWORD Data: 1 After pushing these changes to the clients, reboot and see if the problem gets any better or worse. Also, make sure that the location you placed the folders in (on the 2K3 server) for your clients allows the client "change" NTFS permissions to the folders themselves, and the shares (if you created shares for these) allow "everyone" to have "full" permissions on the sharing tab to make sure users will have the necessary read and write access to the folders.