|
|
Not enough server storage is available to process this command (Solution)
Many times we see this error reported by customers when trying to use one of our programs to update a remote machine.
It has taken us a while to find the source of the error, but it seems that it is an issue with 3rd party applications
http://support.microsoft.com/kb/177078
A registry change needs to be made to accommodate bad behaving programs. It all comes down to a registry key named IRPStackSize.
In Windows 2000 and in Windows Server 2003, the default value of the IRPStackSize parameter is 15. The range is from 11 (0xb hexadecimal) through 32 (0x20 hexadecimal).
If the subkey is not present, you can use Registry Editor to add the subkey. To do this, follow these steps:
1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
3. Click Edit, point to New, and then click DWORD Value.
4. Type IRPStackSize, and then press ENTER to name the value.
Note Type IRPStackSize exactly as it is displayed. This is case sensitive.
5. Click Edit, and then click Modify.
6. In the Data Value box, type 30, and then click OK.
You are probably going to need a reboot for this to take effect.
Posted By: Steve Wiseman on Wednesday, April 18, 2007
Check out our utilities for windows
Windows Vista Resource Kit Released
The Windows Vista resource kit was released this week. I know many administrators have been waiting for it as the previous resource kits have been an invaluable resource.
 Like the previous resource kits it will include tools, utilities, and vital information all in one package. It is currently retailing for $59.99 US. I think I just got it for around $35 from Amazon. So you can find it just about anywhere for much less. From the Vista Team Blog. Here are some of the topics covered in the resource kit:
* Deployment
From installation basics to corporate-level installation guidance for the Business Desktop Deployment (BDD) 2007 for Windows Vista and the 2007 Microsoft Office system, the Windows Vista Resource Kit covers all areas of Windows Vista deployment including:
o Deployment automation
o Application compatibility and deployment
o Disk imaging
o User state migration
o Volume activation
* Management
Controlling how Windows Vista functions and how users access its resources is an important part of supporting the operating system. The Windows Vista Resource Kit covers management topics such as:
o User accounts
o Disks and storage
o Device management
o Printing
o File sharing and collaboration
o Internet access and security
* Maintenance
The ability to restore a system to efficient operation is an important part of a technician's job. The Windows Vista Resource Kit offers guidance for maintenance tasks including:
o Health and performance monitoring
o Remote user assistance
o Software updates and patches
o Client protection (hardening Windows)
* Networking
Windows Vista is designed to operate in networks from two linked home systems to immense corporate networks with thousands of networked computers. The Windows Vista Resource Kit has everything you need to know about the following topics:
o Configuring Windows networking
o Configuring Windows Firewall with Advanced Security
o Connecting to remote networks
o Deploying the next generation Internet-TCP/IP version 6 (IPv6)
* Troubleshooting
Windows Vista is designed to be the most resilient operating system we've ever released. In spite of this, problems do sometimes happen. When they do, the Windows Vista Resource Kit has information on the following topics:
o Startup issues
o Hardware issues
o Network issues
o Stop errors
* Tools and Utilities
In addition to the guidance listed above, the Windows Vista Resource Kit includes a CD of tools and utilities to help you troubleshoot, manage, and configure Windows Vista. Among these tools are more than 150 timesaving scripts to help automate administrative tasks, additional job aids, and an eBook of the entire resource kit.
Obviously it is also a great source of information for cool tweaks and free utilities. You can expect we will be combing through it for any good ideas in this regard.
Posted By: Steve Wiseman on Tuesday, April 10, 2007
Check out our utilities for windows
Forgotten Windows XP Theme - Watercolor
I have been catching up on some reading this weekend. A few weeks back I bought Raymond Chen's book "The New Old Thing". It is an excellent walk through windows history, and why windows does the things it does.
One of the things I came across in the book was about how the Windows XP visual design team wanted to keep their final design secret. This kept any competing operating system from copying the new look before XP was released.
To accomplish this they created a decoy visual style called Mallard. This was an internal name, and it was commonly known as watercolor. They kept the real theme (Named Luna) secret up until the last minute. I did some searching and found an old screen shot of it:(Click to see it full screen)
Actually I kind of like it. I wish you could still install it, but as far as I can tell you can only get your hands on it by hacking old beta copies of XP.
Posted By: Steve Wiseman on Saturday, April 07, 2007
Check out our utilities for windows
.NET will be the downfall of Microsoft Windows
Normally I would not post about development issues here, but while taking a break from working on the latest version of our remote control software I began daydreaming a theory about .NET and its impact on Windows.
We are avoiding .NET like the plague. This is because we want our executables to be small with little or no dependencies. Why? This means our customers will have fewer problems and our software will work on almost every version of Windows in use today (From 95 all the way through Vista when we are finished with this next version).
Another reason is performance. There is simply no way .NET could ever possibly grab the screen fast enough and send it back through the network.
We want to produce a 64 Bit version. Currently we are using Borland Delphi to develop all of our products. To fulfill this mandate we need a 64 bit compiler. The development road map for a 64 bit native Delphi compiler is pegged to be released in the year 2010. Way too long for us to wait.
To solve this issue we are moving certain vital parts of the server side to C++. In this transition we are coming to a sobering conclusion: C++ is discouraged at every turn. Inside and outside of Microsoft.
You will never see anything from MS discouraging the use of C++ (You certainly find it outside!). But little subtleties...like you Google info for a specific API example, and that document is gone. The only info you can find is for .NET - This happens more and more every day. I think eventually it will be very hard to find those C++ examples.
Lets take a moment and summarize what is going on here. Native code is being thrown away in favor of interpreted/virtual machine code. What does that mean for you? More slowness and churn. Why? Native code will *always* be faster than interpreted code.
Now you say...Wait a minute Steve. Hold on one cotton picken minute. This native code argument is crap because processors are so fast now. We have gobs of memory. A little processor speed can be given up in favor of ease of use for developers. Right?
I say no. As time goes by more and more developers will find it difficult, if not impossible to develop native code. Only a select few software development firms will stay the native code course. This means the majority of Windows applications will be interpreted, memory eating, bloated, CPU hogging beasts.
You say again...Steve! You haven't addressed what I said. THIS WONT MATTER SINCE ALL OF OUR COMPUTERS ARE SO POWERFUL NOW.
That is true if you have no point of reference. It all comes crashing down when the same program is written for Mac OS X and under the same exact hardware runs circles around the Windows version.
You see Apple has an easy to use development language (Please debate this another day!) called Cocoa. It still compiles to native code. This means anything developed this way will *always* have an advantage over the .NET/Java style of execution. It is the way Apple has told the public to develop applications for OS X.
This seems minor. But the effect is mathematical. Lets say a .NET version takes 5 seconds longer to load. If you have 20 .NET processes loading at startup it means Windows will take 100 seconds longer to finish than the equivalent processes under Mac OS X. This means from this point on Windows will always be at a competitive speed and memory disadvantage when compared to OS X, or even Linux
I heard someone in the back saying they just go get their coffee while waiting for their machine to start up so they don't care about that. What about the churn. The maddening churn. The churn that makes you want to smash your computer into 1000 pieces. That dreaded clicking of the hard drive when you do any little thing (Since all of your memory has been exhausted and the system has to swap like crazy)
Lets say a .NET application takes 5MB more per process than a native one. (This is a very conservative estimate!) If a user has 20 of these running it will require 100 more MB to handle the same exact setup within OS X or Linux. Even at 2GB I find my machine churning quite often. With the same hardware and same memory it almost never happens under OS X (I would site Linux too...but don't run it on any of my machines right now)
This problem can be directly seen in Vista. Look at the Windows Photo Gallery program. I am almost positive the thing is written in .NET. It performs horribly on what I would call a very powerful machine (2GB of ram with a Core Duo processor). This machine happens to be a Mac Book. A similar application in OS X runs circles around it. Why? Because that OS X application is written in native code.
People will start to notice this. I was never a fan of Apple, or OS X, but 5 second boot times and very little churn have made me use it more and more. I find using Vista agonizing as it sometimes 'thinks' about things forever.
Wait until almost all Windows apps are written in .NET....boy will Windows scream then! Whooo Hooo!
Don't get me wrong. I am no apple fanboy or anything like that....it is just that I see this insidious ticking time bomb in the .NET way of development. When Microsoft realizes the mistake it made it will be too late. Not that it matters much for them since they have so much cash stockpiled - it would take a decade or more of hemorrhaging cash before it even became a problem.
It matters for you and I. We have to deal with the fact that our brand stinking new 2GB of ram dual core machine now runs slower than a machine we bought 10 years ago.
You want to know how I started using OS X? I noticed that when I was in a hurry I could boot up and get into a web browser 10 times faster using it. Eventually I started doing all of my work there. Even windows development! Since OS X has less overhead I can easily run what I need in a parallels virtual machine and get my work done twice as fast. Still I miss having two mouse buttons :(
I bet if I loaded Linux on this thing I would find the exact same to be true. So you see. It has already started. Little ole me - Microsoft fan boy - switched simply because the pain of Windows churn (.NET induced I theorize) was so great it forced me to something else. That pain will cost Microsoft.
Microsoft didn't have to choose this path. They could have easily allowed .NET to compile native code. But they didn't. Delphi is a perfect example of how do exactly that. My insane theory why they didn't is laughed off by most. Microsoft feared the transition between 32 bit and 64 bit hardware.
They felt it could be an opportunity for a competitor to dethrone them. Making .NET an interpreted language makes this transition very smooth. Why? Because Microsoft just needs to upgrade the underlying virtual machine and the application is none the wiser.
A developer can move to the 64 bit platform in .NET with very few changes (If any at all). If most Windows applications were still native code it would require the application vendor to release a new version for each 64 bit platform (At that time 64 bit AMD was *not* compatible with 64 bit Intel). Without this easy transition it would take much longer for users to switch to 64 bit.
So they traded off speed in favor of continued dominance in the industry...only to doom themselves later on!
So that's my theory and I am sticking to it. Only time will tell, but I bet we will still be talking about how long it takes for applications to load 5 years from now. That problem won't go away because we have faster machines.
Posted By: Steve Wiseman on Thursday, April 05, 2007
Check out our utilities for windows
Vulnerability in Windows Animated Cursor Handling
This problem seems to getting worse by the minute. If you have not heard about it yet there is a mouse cursor vulnerability in just about every version of windows. Currently it can be exploited by creating a specially crafted website and trick a user into visiting it. Any version of IE is vulnerable. Let me say that again. You only need to *visit* a site to become infected.
Microsoft has known about this problem since December, but it has only become a problem recently as an exploit has been showing up in the wild. They promised a patch today, but still nothing at the MS website. Hopefully we will see something later today.
You can get all of the details from Microsoft here
I would suggest using firefox for all of your browsing, or if you must use IE I would suggest utilizing our free reduced permissions program for IE. It can be found at the bottom of our downloads section
Make sure you have the latest signature files for your virus protection too.
Posted By: Steve Wiseman on Tuesday, April 03, 2007
Check out our utilities for windows
ISA Server and 2003 SP 2 Troubles
Microsoft has had about 400,000 downloads of SP2 for 2003 so far, and they are starting to get a number of reports from customers running ISA server.
Here are the specifics from a MS Blog on the subject: 1. If you run ISA Server 2004 Enterprise Edition with or without the ISA Server SP2, you must install ADAM SP1 on the ISA Server Configuration Storage Server prior to installing the Windows Server 2003 SP2. ADAM SP1 can be downloaded from here. If you install Windows Server 2003 SP2 without first installing the ADAM SP1, ISA Server will not start after the installation, and you will have to uninstall Windows Server 2003 SP2. Further information is available in the Windows Server 2003 SP2 release notes, from here.
2. If you run ISA Server 2000, 2004 or 2006 Standard or Enterprise editions on a multi-core / multi-processor 32-bit computer, and the CPU is heavily utilized, you might experience performance degradation in certain deployment scenarios after installing Windows Server 2003 SP2. The issue stems from a change in interrupt handling introduced in SP2. To correct the issue you must download and run the Interrupt Affinity Tool (intfiltr) available in Windows Server 2003 resource kit. You can read about installation and usage of intfiltr.exe from here.
3. If your network adaptors (NICs) support receive-side scaling (RSS), then in certain NAT scenarios ISA Server 2000, 2004 or 2006 Standard or Enterprise editions might not transfer packets from one NIC to the other after installation of Windows Server 2003 SP2. To correct the issue you must disable RSS support - follow the instructions from here.
We are still testing SP2 here, and have not found any issues...but it would be a good idea to test on non-production servers before deploying SP2 on your network.
Posted By: Steve Wiseman on Monday, April 02, 2007
Check out our utilities for windows
|
 |
