The Mole #30: Technical Answers from Inside Microsoft - Monitoring Servers, Passwords, Drive Mapping, Access Utility
March 13, 2000
Editors Note The questions and answers below are from the Inside Microsoft column that appears regularly on the TechNet Web site at the following location: https://www.microsoft.com/technet/community/columns/insider/default.mspx. To find out how to submit questions of your own, see the end of this article or go to https://www.microsoft.com/technet/community/columns/insider/default.mspx.
The TechNet Mole provides expert answers from deep within Microsoft to questions from IT professionals. This installment focuses on these issues:
Performance Data Log Service fails to perform
The Passwords that will not change
Make that drive-mapping go away!
Access databases and a JetComp Wish List
BackTalk: VPN to Internet/Need a second dial-up adapter
On This Page
Performance Data Log Service fails to perform
The Passwords that will not change
Make that drive-mapping go away!
Access databases and a JetComp Wish List
Backtalk: VPN to Internet/Need a second dial-up adapter
Credits
Performance Data Log Service fails to perform
Hi!
I'm trying to use the Performance Data Log Service (PerfLog) from the Windows NT® Resource Kit to monitor about 25 servers. The data from the .csv files will then be imported into an Access database for further manipulation.
I set up the Pdlcnfig.exe with all the objects, counters, and instances I want to log. When the datalog was done, only one server showed up, in addition to my personal workstation.
I don't know what I'm doing wrong. We have SNMP on every server and workstation, and I've already installed the PerfLog on every server as well.
Can you help me? What am I configuring wrong?
Huei
Whoa, Huei.
Your willingness to assume the problem is yours is refreshing, of course, but now, repeat after Mole, That #@&^ utility doesn't recognize 24 of my 25 servers! What the &^($ is wrong with it?
Or, as Mother Mole once said, "never volunteer to take the blame." (Feel better already don't you?)
And now, to get the rest of you up to speed, the Windows NT 4.0 Workstation Resource Kit includes a utility called Performance Data Log Service. The executable is Pdlsvc.exe, and it's used in conjunction with Pdlcnfig.exe. This utility functions much like Performance Monitor, except Performance Data Log Service runs as—duh--a service. It logs data from performance counters to tab or comma-separated variable files. These in turn can be used as input to spreadsheets, databases, and other applications, as well as to Performance Monitor itself. It lets you choose which performance counters you want to log, and starts new log files automatically at intervals you select.
Sounds like a utility made in heaven, right? By nosing around, Mole's unearthed info about a little bit of trouble in paradise. The thing is, Pdlsvc.exe was never designed for use in production environments. It's a wee bit flightier than one might wish in certain situations, posting sporadic problems with counters remotely, sometimes even locally.
When you add eight or more servers to the Performance Data Log Service utility, reports suggest you may encounter one of the following symptoms when you attempt to stop the service:
Error: "The instruction at "0x77f64c5f" referenced memory at "0x013ab60d". The memory could not be "read". Click on OK to terminate the application."
-or-
Error: "The instruction at "0x77f64c5f" referenced memory at "0x013ab60d". The memory could not be "written" Click on OK to terminate the application."
-or-
The service is not stopped.
The symptom usually occurs shortly after adding or removing computers, or when starting or stopping monitoring. Are we discouraged yet?
Consider this alternative...
But wait. Mole has another idea. Consider using a different utility in the Windows NT 4.0 Workstation Resource Kit, the one called Monitor.EXE. Monitor is the configuration tool for installing and controlling the Data Logging Service (DATALOG.EXE). It performs essentially the same function as Pdlsvc.exe, better, or at least more reliably, when you want to remotely administer log files for a whole lot of computers.
Whew!
Yr furry friend
The Passwords that will not change
Hi Mole
A little problem with passwords!!
Out of 350 users I have 5 that when it comes time to change their passwords, the PCs freeze up, then come back with permission to change password denied (C00000BE). All the PCs are identical, all setup with an unattended install, user privileges etc. Can you help?? It's probably something simple I am missing.
Paul, Inchcape Motors Australia
Paul, Paul, Paul!
Mole's fur is ruffed up. He growls softly. He wags a claw. Why? Because you've neglected to give him the nitty gritty details about your client configuration, that's why.
Please, all, give a thought to Mole's blood pressure and his mental health. Remember to include the juicy details—what OS, what version, with which service packs installed, where, not to mention which error messages are turning up on your screen.
Okay, ten minutes of yoga here in the burrow and Mole's calmed down. It's not your fault. Repeat, not your fault. Now that Mole has his fur straightened out, he believes he can help you, though his solution is necessarily based on a series of assumptions. To wit:
You receive the error message "Unable to change password on this account (C00000BE)."
The clients are Windows NT 4.0 with Service Pack 3.
The domain controllers are Windows NT 4.0 with Service Pack 4.
You are required to change your password the next time you log on (it has expired or the administrator has selected the User Must Change Password at Next Logon check box).
You have installed the Restrict Anonymous hotfix from **143474:**Restricting Information Available to Anonymous Logon Users.
The thing is, there's a problem with Service Pack 3 that causes this. The resolution is to upgrade the clients to the latest Service Pack, which at this time is Service Pack 6. In fact, you should make it your policy always to have clients and servers running the same version of the Service Pack at the same time.
This is not unlike Mother Mole's practice of taking aspirin BEFORE she gets the headache.
Make that drive-mapping go away!
Hi Mole,
I'm looking for a way to forcibly disconnect a drive mapping under Windows NT 4.0 Workstation from a batch job.
I know you can use net use x: /d to disconnect a drive connection, and net use x: /d /y to close open files and close the connection - but when you have, say, an Explorer window openreferencing the drive, and attempt to disconnect the drive, you get the following error:
An active process is accessing the device. More help is available by typing NET HELPMSG 2404.
Is there a way to forcibly disconnect the drive?
John Bishop, MCSE, Australia
Hi John.
You have some process that's using the drive. Until that process, in this case, Explorer, is done doing what it needs to do, you're not going to be able to disconnect from the drive. Bummer. It would be possible to resort to the Windows NT Resource Kit "Kill" command, which is used to terminate unruly processes, but Mole doesn't recommend it—too heavy-handed.
Now, Mole's confidence in his response to your question would be much greater if you'd thought to mention which Service Pack you have installed on your workstation (Gentle readers, do you begin to sense a theme here?) Because, in fact, there was a problem with this very issue in Service Packs 4 and below, which is, happily, repaired in Service Packs 5 and above, which is to say, in 5 and 6.
Read more about the fix in Knowledge Base article **214563:**NET USE /d Returns Error 2404 After Applying Service Pack 4.
The only other solution Mole can think of is to take up a hobby to pass the time until Explorer has finished up its business—admittedly, not ideal.
Access databases and a JetComp Wish List
Hi Mole
One of the most tedious jobs of a database administrator is keeping the database in good working order.
This is especially true of the thousands of souls that maintain Access databases, using the new Microsoft utility called JetComp.exe. Only problem: it does not support a command line interface, so us poor suckers have to laboriously run this utility on a daily basis—usually before all the other staff arrive.
Any solutions? As an aside, I am probably the only person in the world who has been bitten by a mole! You would never believe the circumstances.
Sandy McKella
Dear Sandy,
According to the Nebraska Department of Health and Human Services, 8 moles were tested for rabies between 1992 and 1995. Alas, Mole's kinsmen would not have been subjected to such clinical scrutiny had they not sunk their teeth into human flesh. The Nebraska DHHS Web site lists a number of possible provocations for wild animal attack, such as startling the poor creature, taking away its food, bugging it when it's sick, or riding by on one of those annoying bicycles. Forgetting to say which version of the software one is running and which service packs one has installed do not presently appear on the list, though Mole is lobbying for their inclusion.
As to the Daily Tedium of the Database Administrator (the movie version will star Jeremy Irons), Mole CAN help. Let's assume for the moment that you're running Access 2000. If so, you're in luck because the Jetcomp version (4.0, in case you're curious) that comes with Access 2000 CAN be used from the command line. To find out the parameters, just type the following at a command prompt:
Jetcomp.exe -?
Another option you might consider is a 3rd party utility—free, by the way—called "TSI Compactor". Not only does this utility allow you to compact an Access database, it also contains a special method that supports remotely compacting a database that sits on a Windows NT Web server. AND it has a really cool progress meter! Go to https://www.trigeminal.com/lang/1033/utility.asp?ItemID=2#2 for more information and to download. (Disclaimer: This is not a Microsoft product. Knowing its in and outs is not part of Mole's job description. Direct your questions to the folks who wrote it, at Trigeminal Software, Inc. (https://www.trigeminal.com/). See Mole set boundaries.)
And if you're running an earlier version of Access? You can accomplish compacting and repair a database using an Access macro. This approach requires basic macro, coding, and interoperability skills and applies to Access versions 1 through '97. Rather than duplicate the procedure, Mole will refer you to the Knowledge Base article that gives you all the information, OK? Here's the link—**100923:**Sample Macro for Repair/Compact Operations.
Mole (who rarely bites, never without cause)
Backtalk: VPN to Internet/Need a second dial-up adapter
In the January 17th Mole column, IT Pro Anthony Giannattasio reported that though he was otherwise much pleased with his VPN, the only ISP connection that he could successfully initiate and log on to the Internet through was AOL.
Now IT Pro Mike Camisi sends these very fine thoughts on the matter. Mole suspects he's nailed the problem.
Mole,
I just wanted to make a comment on the post titled, "His Point-to-Point Tunnel is stuffed up".
My thinking is that the VPN Dial Up adapter is not set up correctly on that machine. The reason it works with AOL and no other ISP is because AOL installs its own dial up adapter, and uses that for connections to AOL (leaving the first Dial up adapter free for other use). In order for PPTP to work, you need to install a second Dial Up adapter. After you install it, it will say "VPN" (or something to that effect) next to it, if you have everything else installed properly. Make sure you then have TCP/IP bound to that adapter. This will then allow you to dial in to your ISP on your first dial up adapter, and then use the second adapter for the VPN connection.
The Network Properties should show a Dial Up Adapter, and AOL Adapter, and Dial Up Adapter #2 (VPN) when you are finished. I do not think the problem stated is a problem of the ISP not supporting PPTP. If there is only one dial up adapter installed on that machine, you would get "The dial up adapter is in use..." error when trying to make your VPN connection, because indeed, the dial up adapter is in use by your connection to your ISP (other than AOL). Just a thought.
Mike Camisi
Credits
The incomparable Mr. Lon Collins. His colleagues, Kevin Mineweaser and Michael Kaplan.
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.