Mr Snrub

Okay, well that would imply the driver it quite happily determining Aero Glass support is possible, but some resource is running out or a threshold being exceeded when you ramp up the requirements too high.What about 1280x1024x16? Does Aero Glass work then? Not sure if the req's for beta 2 just raise the bar a bit and your current GPU can't cut it... this is an AGP card right? 512MB system memory... have you tried tinkering with the AGP aperture size in the BIOS at all? The rating tool is pretty clear - the weakest link there is the GPU and the graphics memory.

Let me re-word it - what if you make the screen resolution lower, for example 1024x768? Does Aero Glass work then? I tink 88.61 came out to coincide with beta 2, so you'll not have tried that version with a previous build... so we don't know if it's the later build of Vista or the later ForceWare driver. If you have the older build you could always verify with the 88.61 driver to see if it's the driver or not.

It sounds like the option in the Screen Saver settings "On resume, display Welcome screen". Right-click the desktop, click Personalize Click Screen Saver Untick box "On resume, display Welcome screen", click OK

If you lower the resolution does it allow you to enable Aero Glass? What's the version of the nVidia ForceWare driver you have installed?

You're lucky nv4_disp.dll is the root cause for a huge number of bugchecks, as are AV filter drivers.

You're taking it out of context - the Standard features require a WDDM display adapter rather than the current classic style driver, and it is here the inherent increase in stability arises, as it's a different driver model.The Starter version of Windows is aimed at much, much lower spec machines which are not capable of WDDM anyway. Home Basic and Home Premium both will support WDDM display drivers, going from that chart.

The Windows Vista page over at Microsoft has quite a bit of info: The Features Performance

The client machine as a whole uses multiple source ports for its concurrent connections - otherwise waiting for a webpage to load would be a horrible experience.First you GET the HTML source, then you do a GET for each page element (scripts, CSS files, images, plugins, etc.) and these occur concurrently - if only one source port were available then they would queue up and rendering a simple page would take a lot longer, regardless of how much bandwidth you might have. I know but it still affects a lot of other things. And I know how concurrent connections work......But unfortunatly, p2p doesn't use 3999 ports, it only uses 1 at a time. What can I do about that other than write my own (which I don't know how)? This last statement shows you still don't have a grasp on how TCP works - outbound connections use local source ports in the range 1024-5000 by default.The whole reason P2P suffers a performance hit when starting up is that it tries to use a large number of these ports to test if various other people downloading or seeding the file at that time are available, of which many will be firewalled and hence unresponsive. P2P uses one port (or a small range of ports perhaps) for inbound connections and it will use many ports for outbound connection attempts. Once the P2P client has got up to speed (the firewalled users have timed out and the actual sharers are connected, the performance picks up and the transfer will gain speed. If the tracker servers maintained a dynamic list of which connected users were not firewalled then it would make the whole system much more reliable - the clients do not have to probe to see if the other users are able to receive connections as the server will have done it and can tell them. Like I said, it's a design flaw with the current implementation of P2P. We have gone way OT for this thread now, however PM me if you have any questions on this.

This is often mis-stated - the limit is on outstanding (i.e. incomplete) TCP connections from the machine.This was introduced to prevent the impact of worms from infected machines, reducing the potential rate at which they can spread dramatically. TCP connections to valid services are very quick to set up, so the chance of hitting >10 connections being built at the same time is slim (plus the stack backs off and retries automatically). By default Windows has just under 4000 ports available for outbound connections and this limit has not been touched - they can all be in use simultaneously. P2P software performance can be affected because of its poor design, and the fact that so many users are firewalled and use "drop" instead of "block" rules, so the outgoing connection attempts have to time out.

XP SP2 contains ALL hotfixes released for Windows XP up to a certain date (around July 2004).It is not just major updates or security hotfixes, the latest version of every binary which has been changed since the release of Windows XP is included (not just since SP1). Similarly, when SP3 comes out it will contain every binary that has been changed up to shortly before the date it is released.

Unfortunately this would negate the whole purpose of UAC.The example commonly used is the Microsoft Management Console - mmc.exe - which is the "shell" for various management functions in Windows. If you allow this executable to do admin tasks unchecked until it (mmc.exe) changes, then everything from Device Manager to DNS to Windows Firewall with Advanced Networking is tarred with the same brush. UAC should only kick in for administrative tasks (messing around in Device Manager or Advanced Computer Settings, etc.), actions which affect all users (deleting or creating files in the "All Users" profile), or when badly-coded apps demand access to protected parts of the OS (registry mirroring gets around some of this, but if an app wants read/write access in system32 then it could still trigger it).

Boot in Safe Mode and you should find the Administrator account accessible, then you can create another user account with a password and reboot in regular mode (Administrator account gets automatically re-disabled).

Not me.I'll take kernel security and stability over badly-coded apps any day. It should not be necessary to modify the running OS kernel to achieve a goal, and I also like the required signing of kernel mode drivers in 64-bit versions of Windows. Black lists would never work, as has already been alluded to "if there's a will, there's a way". Polymorphic code with random filename generation would render a blacklist useless. Ultimately this should force vendors to write software in a better way, and prevent a large number of bugchecks that never get resolved. Hooking kernel code relies on either very clever coding or each version of the product will only work for a specific version of the kernel. Edit: Having this as an "opt-out" feature would also negate the point of the exercise - social engineering, user stupidity or plain ignorance could lead to it being disabled by malware, leaving it wide open for any kernel patching including rootkits. This is also not a new feature - this KB article is making enhancements to the existing 64-bit kernel protection. It is this protection that has prevented "rootkit style" code working on x64 versions of Windows.

Well, it has a "network shield" which can be considered a basic IDS system, not a personal firewall with control over which program uses which protocols to which destinations, or which can run as servers.Actually, Vista has a built-in 2-way firewall - launch mmc.exe and look for the "Windows Firewall with Advanced Security" snap-in. As with XP's firewall, it is blocking inbound traffic by default, with a simple list of exceptions such as remote assistance, MSN Messenger, etc. The outbound protection is by default turned off - in that it defaults to "allow all". You can either select to change the default to "block" and then set up exceptions for eveyr program or port that you want, or add specific block rules if there are programs or specific protocols you don't want to permit. When deploying XP SP2 desktops in a corporate environment you can specify different rulesets based on whether the client is connected to the domain (trusted network) or elsewhere (untrusted). Now, with Vista, you have 3 options - domain, private and public. So you can create a ruleset for your company LAN, one for home LANs or other "semi trusted" networks, and one for untrusted LANs such as wireless hotspots where you may want to block all but VPN to the office. For home users it may be simpler to get a 3rd party firewall when there are Vista-friendly ones, but for companies the built-in one is much more feature-rich for "real" firewalling, including application-layer (not "personal information vaults" and such). The home user might find it too much administration to manage the Vista firewall for outbound, with a "default block" policy as there aren't any visible indicators when something is prevented from communicating, and logging is not enabled by default either.

Bingo!At least one person gets it As for "Threre are a few % who fooled by pirates comparedto those who delibrately use it." - how do you know? All it takes is for a few companies to have paid a 3rd party for a "discounted" volume licence for their thousands of client machines, but it turns out that it's not actually legal and Microsoft never saw any of the money... and this does happen. The company bought the software in good faith, perhaps even the reseller sold it in good faith, but their supplier might have sold them dodgy pirated software. This happened to one of our suppliers of IT software and hardware when I worked for a bank in the UK - a reputable company, but they got hoodwinked by one of their suppliers. The end users didn't know they had pirated software, the reseller didn't know they were selling pirated software - a tool wuch as WGA is the only feasible way for these people to be aware, not to punish them but to help identify the origins of the priacy rings. This is not to try to persuade the end users that deliberately installed illegal software to mend their ways, but to make people who paid for illegal software aware that they did so.

You shouldn't believe what "ppl" say then... I just installed FSRM on my 2003 R2 virtual server and it works perfectly:Repro steps: - Installed File Server Resource Manager through Add/Remove Programs / Windows Components - Rebooted as requested (it installs some filter drivers to monitor file access) - Created a folder "c:\test" - Launched the File Server Resource Manager administration tool - Created a hard quota on c:\test restricting the space to 5MB - Copied a "testsrc" folder containing 2.6MB of data into it (worked fine) - Attempted to copy the same folder in again - got an error (5.2MB > 5MB) Screenshot here shows there is plenty of space on C: itself, the size of the test data, the quota rule and the error when trying to move the data in which would exceed the quota:

I assume from the format of the error message it is the common:"Application error. The instruction at "%l" referenced memory at "%l". The memory could not be "%s"." Where %l is a memory address and %s is either "read" or "written".

At a guess, it can't locate winsat.exe.Did you install it to a non-default folder? Might be worth running FileMon while you run the tool, to see where it is looking for winsat.exe (if it is indeed "file not found").

Can you launch mmc.exe by itself without it crashing? Can you view the services through: - right click My Computer - click Manage - expand Service and Applications - click Services ? Is this 2000? 2003? What service pack? What apps/services are installed on the server?

File Server Resource Manager sounds like the information you are after. "By using File Server Resource Manager, administrators can place quotas on folders and volumes, actively screen files, and generate comprehensive storage reports." I only have the Enterprise Edition, but based on this hotfix saying it applies to Standard, Enterprise & Datacenter, I assume it's in all flavours. The Storage Management section on this page makes interesting reading for a feature overview.

Quick answer to this is yes.Service packs are cumulative, so starting at XP RTM then applying SP1 then applying SP2 is identical to starting with XP SP2. When it comes to Windows updates, XP SP1 + all the hotfixes delivered by Automatic/Windows Update will not be as complete as applying SP2. Some hotfixes are not security-related and so applying them puts you into the QFE branch of the OS instead of staying on the GDR branch, these you have to request from Microsoft to address a specific issue, some of which are documented in KB articles. Service packs contain every updated binary since the previous checkpoint, not just security ones, and keep you on (or return you to) the GDR branch.

This would imply a failure to get a valid DHCP lease - the "limited" part means that Windows assigned itself an APIPA address (169.254.x.x).Check the basic things first: - when the ethernet cable is connected to the computer and the router, do you have lights a both ends? - have you tried a different cable? - are there other computers using the router that are not having problems? - have you tried power-cycling the router? Start "cmd" at the Run prompt, then enter the following command: ipconfig /all What does that report? If even connecting the modem into your computer directly doesn't work, I suspect your NIC or cable has had it. Or possibly you installed some beta software which puts a filter driver into the network stack like I did with the 64-bit version of Zone Alarm, and it subsequently borked all IP connectivity through my NIC - but I think you would know if you had done something like that I would disregard any advice about uninstalling SP2.

Your "General" tab seems a little bare - did you manipulate the image, or is this system nLited? Are you logged in as an Administrator? Is this machine in a domain? What is the status of the Terminal Services service? Started or Stopped? If you go to a command prompt and enter the command "netstat -ano", does it list TCP port 3389 as LISTENING? Edit: Also check the following 2 registry values: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\TSEnabled => This value should be set to 1 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\fDenyTSConnections => This value should NOT be present (delete if you find)

Short answer: no.Not a simple variable as used above - you would need to do a bit of work (or call a 3rd party tool) to achieve that. To get the display name without a separate tool you would need to construct and perform an LDAP query (or series of queries, recursively) against a DC (or number of DCs, to guarantee a result) to locate the user object based on its distinguished name and then a perform a query against it to get the DisplayName property out. There are way too many things that can go wrong here to make it worthwhile breaking my scripts above which are simple yet functional. You could try to parse someting like the output from GPRESULT or WHOAMI but I wouldn't consider it worth the bother. I don't know of any WMI class that can be used to obtain the display name of the currently logged-on user, only user accounts (local and domain).

Handling of UNC paths is not usually a problem, however a command prompt does like a drive letter associated with it to have a valid current working directory, so if the batch file were not local then it could have a problem. You could have the batch file present somewhere on each client's local drive, locked in by Deep Freeze, then use either a local policy or group policy to start it to avoid this problem. Or, you could use a script to achieve the same result and this can happily be run from a UNC path (such as the folder where the group policy files are located on the DCs) - this would save you having multiple copies of the script/batch file all over the place: Logon Script: ' Variables for use in the script const ForAppending = 8 dim objShell dim strUsername, strComputername, strSession dim objFSO, objFile dim strFilename ' Get the environment strings into variables Set objShell = WScript.CreateObject("WScript.Shell") strUserName = objShell.ExpandEnvironmentStrings("%USERNAME%") strComputerName = objShell.ExpandEnvironmentStrings("%COMPUTERNAME%") strSession = objShell.ExpandEnvironmentStrings("%SESSIONNAME%") ' Prepare the file for appending, create if necessary strFilename = "\\SERVERNAME\SHARENAME\FOLDERNAME\logon-logoff.log" Set objFSO = CreateObject("Scripting.FileSystemObject") Set objFile = objFSO.OpenTextFile(strFilename, ForAppending, True) ' Write the line to the log file objFile.WriteLine(Date() & " " & Time() & " - " & strUserName & " logged ON to " & strComputerName & " (session: " & strSession & ")") ' Close the file objFile.Close Logoff Script: ' Variables for use in the script const ForAppending = 8 dim objShell dim strUsername, strComputername dim objFSO, objFile dim strFilename ' Get the environment strings into variables Set objShell = WScript.CreateObject("WScript.Shell") strUserName = objShell.ExpandEnvironmentStrings("%USERNAME%") strComputerName = objShell.ExpandEnvironmentStrings("%COMPUTERNAME%") ' Prepare the file for appending, create if necessary strFilename = "\\SERVERNAME\SHARENAME\FOLDERNAME\logon-logoff.log" Set objFSO = CreateObject("Scripting.FileSystemObject") Set objFile = objFSO.OpenTextFile(strFilename, ForAppending, True) ' Write the line to the log file objFile.WriteLine(Date() & " " & Time() & " - " & strUserName & " logged OFF " & strComputerName) ' Close the file objFile.Close This appends all the logon/logoff events into a single log file with the date, time, client name & session ID (so it covers Terminal Services too). Save them as 2 separate .vbs files and create a group policy with them both called accordingly via: User Configuration / Windows Settings / Scripts (Logon/Logoff) -> Logon User Configuration / Windows Settings / Scripts (Logon/Logoff) -> Logoff Copy the .vbs files into the folder in the SYSVOL share where the policy resides and they are guaranteed (so long as the client has a working scripting engine) to execute if the policy is processed.