Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Another possibly strange remote registry issue

  • Thread starter Thread starter MPB
  • Start date Start date
M

MPB

Mar
35
1
Thanks again for fixing the @regbread issue on remote reads so quick.

One other odd thing I found... I'm testing out using:
iff %@regexist[\\%comp%\HKLM\Software] EQ 0 then
sc \\%comp start remoteregistry > nul
endiff

Okay, pretty simple, try to read a key we know is there, and if it can't be read, assume the remote registry service isn't started (I preface that with a check to see if the machine is pingable).

I expected it to return a zero in a case where the winreg remote pipe wasn't responding, indicating that service is stopped. What I get instead is:
TCC: (Sys) No such host is known.
"\\<the computer name...>"

I just assumed it would return a "zero", same as if the machine were reachable but the key didn't exist. As it is, it throws an error in the iff/then and continues on to the "sc start" command. Which is fine in this case since that's what it would do in that situation anyway, but in a different case that could be the wrong next step. :)

What I was using in my old TCC v14 script was using "reg query" to do the same, and I can keep using that I guess, I thought I'd just try out some fancy JPSoft only tricks for the registry parts of my script...
reg query \\%comp%\HKLM\Software /ve >& nul
iff %? NE 0 then
sc \\%comp% start remoteregistry > nul
endiff

So I have a workaround, but thought I'd see if the @regexist for a remote machine that wasn't reachable through that remote winreg pipe was by design, or... ?

By the way, I used the now-working @regbread to read in some Groove sync client reg_binary key info and being able to parse that to get the local and URL info for what the client is syncing is WAY better looking than the ugly method I had been using, parsing the raw binary and converting to text, character by character. The @bpeekstr was especially useful, having the unicode option built in. Very cool.
 
Sometines this happens (after a 20 second delay).
Code: 
v:\> echo %@regexist[\\qqqq\hklm]
TCC: (Sys) The operation completed successfully.
 "\\qqqq"
 
Here's another curious output... instead of just doing an "echo", try setting a variable to the output of the @regexist (it's important to make sure the remote computer actually exists/resolves, otherwise you'll get the "no such host" error which makes sense):
C:\> set x=%@regexist[\\actualcomputer\HKLM\Software] TCC: (Sys) The operation completed successfully. "\\actualcomputer" C:\> echo %x ECHO is OFF

By comparison, if the remote registry service is actually running on that remote machine, the "set" command works (no output) and "echo %x" returns 1.

The problem as I saw it was that I was trying to use it as a way of seeing if the remote registry service was actually running, by reading an arbitrary (but always present) key on the remote machine, and turns out that's not possible without parsing the text itself from the stderr output, looking for text that could very well change from version to version?

I don't really know what the answer is besides maybe returning a -1 for @regexist if the machine wasn't reachable (or not even resolvable. That might be safe enough so that people checking for "if %result% GT 0" to see if it succeeded are still getting what they want?

Not really complaining since I can do it with "reg query" and get the errorlevel from it which gives me what I need. Not sure if I'm missing any other really obvious ways of doing it?
 
You must log in or register to reply here.
Back
Top