Tech.It.2.Me->{By.Anton.Perez}

Here’s a diagram (on the Guardian website) showing the fiber optic cables under the sea that connects the world together.  Very interesting!

My friend Anthony was getting “access denied” and “logon failure” errors when trying to to run psexec (from one of the PsTools suite) from an XP machine on a domain to an XP machine in a workgroup.  It was something similar to:

PsInfo 1.34 – local and remote system information viewer
Copyright (C) 2001-2002 Mark Russinovich
Sysinternals – www.sysinternals.com

Could not connect to machine_name:
Access is denied.

And…

PsInfo 1.34 – local and remote system information viewer
Copyright (C) 2001-2002 Mark Russinovich
Sysinternals – www.sysinternals.com

Couldn’t access machine_name:
Logon failure: unknown user name or bad password.

Here are the settings/steps I checked/took that resolved the issue:

1. ping - was able to ping the machine by hostname.  So no problem here.

2. net share - verified the ADMIN$ share was enabled.  Again no problem here.

3. Remote Registry service - verified the service was started because the PsTools suite makes use of RPC calls via port 445.  Was fine here.

4. Administrator password - verified the Administrator did not have an empty password.  Was set here.

5. Test account - created a test account to use for psexec (e.g., psexec \\computer_name notepad.exe -u test -p test).  Was available here.

6. Access hidden share – tried to access C$ and found that user name field grayed out.  This tipped off the problem – cool!

To fix it, I had to set the Network Access: Sharing and security model for local accounts security option Classic – local users authenticate as themselves.

Access it via Start > Run > secpol.msc > Local Policies > Security Options (see screenshot below).

Apparently, updates to Windows XP now sets this security option to Guest only – local users authenticate as Guest, which denies the ability to implicitly or explicitly use of a specific user name/password combo.

Hope this helps someone out there.  Peace.

My Vista lab box presented this error when I tried to login into my company’s domain after several months of not doing so:

Trust relationship between this workstation & primary domain failed

I suspected my [Vista] installation was using cached domain information to login, which was the case and why it was being denied access.  This is because a computer that is not active for a certain period, is usually removed as a member of the domain. 

If you encounter this, you’ll need to rejoin the computer to the domain via My Computer > Properties > Computer Name > Change (you may need Help Desk/IT to do it for you).

I read about it via The Register…ICANN set up a new IP address for one of the “root name servers,” and is retiring the old address, i.e., from 198.32.64.12 to 199.7.83.42.  They’re apparently doing it for two reasons:  For one, the old IP address wasn’t officially under ICANN’s control.  But (two) more importantly, the organization wanted to make the switch to “any casting,” a way of streamlining DNS queries.

Take note that each “root name server” is actually a collection of several physical servers, and with anycasting, ICANN can spread its machines across multiple geographical locations.

Read more via The Register.

If you like (or are required) to help/assist people with their wireless router needs, you’ve probably had the need to reset and reconfigure them many, many times.  The problem, however, is that most of time time you don’t have the admin username and password to do so; you ask them if they have their user manual laying around somewhere, or just google it, right?

Well then…to make your life a lot easier, here’s a great site that you can take advantage of.

Take care!