Performance counters on SYSIMG1 became corrupted recently. The MS KB is full of strange and dated advice on the subject. Here is the most recent article I could find:
It is full of tedious and laborious steps to manually repair the performance counter object mappings. Towards the bottom of the article, we learn that on Server 2003, the following console command will restore corrupted counters, thus obviating the need for any manual config steps:
This will re-read all of the perfXXX.ini files in the system32 directory and rebuild the counter data. If you have any apps running that do not house their .ini files in “system32” you will need to load those manually.
In any event, the above command fixed the problem on SYSIMG1 quite nicely. Thanks, MS!
We had some fun adding Intel SATA drivers for the new Intel chipsets onto our RIS server. These drivers are required in order to deploy RIPrep-generated images onto the new Gateway M285 Tablet PCs.
Here were the key steps, as outlined in this TechNet Article:
Some interesting things that we discovered in making this work:
- PNP NIC drivers that are accessed during the initial NDIS driver load can be added to ANY flat image on the server. A Tablet PC will access drivers from the “XP SP2” Flat image. If you have more than one version of the same driver in different folders, only the first alphabetically listed driver will be made avaialble to RIS net boot clients.
- Text-mode setup drivers (which generally are mass storage drivers) are loaded when setup.exe starts in earnest, after the NIC load process. These drivers must be available in the $OEM$ directory of the platform for which you are loading an image (RIPrep or Flat). If you are loading an RIPrep image for a Tablet PC, you must have appropriate drivers available in the Tablet PC flat image.
I have installed an instance of WDS on our current production RIS server. No worries, RIS functionality is still present, fully unadulterated.
However, I seem to be having problems getting a PXE boot client in my office to load. PXE boot works, and the WIM image gets loaded onto the workstation. However, I get a “unable to communicate with the WDS server” error after the GUI loads.
Some Ethereal packet captures show that the client is sending a port map request to the server, and the server is telling the client to connect to port “5040”. This value is not in our range of pre-allocated RPC ports, so I assumed that this port is hard-coded into the WDS service.
Sure enough, a quick registry search reveals that this is a parameter of the WDSServer service:
The default value was “5040”. I changed it to be within our range of excepted RPC ports, then ran:
net stop WDSServer
net start WDSServer
Lo and behold, I can now boot to WDS and install Vista. Cool. Now they just need to get the bugs out and give us the RTM WIM files. We will be ready!
Note: Net booting the install WIM is kinda pokey. I think I will try making a bootable USB drive next. I think this might be our best option for mass distribution.
“How long do we need to wait to be confident that software that isn’t
installed won’t crash?”
in written communication to a Dell support “engineer”
I am attempting to model the upgrade of our existing WSS 2.0 site to 3.0 using the current “beta 2” release. Fun so far:
- The installer for WSS 3 refuses to run claiming that I need Workflow Foundation v2.2 installed and ASP.NET 2.0 enabled on my site. Workflow foundation can be downloaded from http://www.microsoft.com/downloads. The ASP.NET issue was a bit more puzzling, since I throught I already had .NET 2.0 installed on the test server. A quick investigation revealed that it was installed, but not configured for or activated in IIS. I just ran the .NET framework installer again and now the installer runs.
- all of the pre-release documentation and the current “readme” file are available at http://www.microsoft.com/downloads. Irritating that they did not come with the beta 2 download… I had to hunt them down.
- After install, configuration failed. I had to run the “prescan” tool manually. The report that was generated showed that two sites were “broken”. Interestingly, I could not find any evidence that these sites actially exist when using either “stsadm -o enumsites” or the “Sharepoint Explorer” utility. Some googling revealed the concept of “site oprhans”:
It is claimed that there is a tool available to fix this:
But as luck would have it our MS Essential Support has lapsed and Procuremetn has not processed the service renewal request. Dang! I will just fix the problem manually on the test server, but we will need that hotfix for Prod! Manual fix entails removing the content database from the virtual server, then adding it back in. This forces the Config database to remove all current entries, then recreate them.
- next problem is vexing… I get this error during the upgrade process:
An exception of type System.Runtime.InteropServices.COMException was thrown. Additional exception information: The Indexer property in the MSSConfiguration table is not set to the name of this machine.
System.Runtime.InteropServices.COMException (0xC0041229): The Indexer property in the MSSConfiguration table is not set to the name of this machine.
I just can’t figure this one yet. Google is worthless.