How NT-style machines handles remote connection attempts when you aren't in a domain is a little confusing, because under the hood the basic security system wasn't designed with workgroups in mind. Basically, in a workstation every computer's account database is completely separate and there is no way to set up any kind of even partial trust relationships or to refer to accounts on other workgroup machines in ACLs.
When you do a remote connection to another machine, the account you are using at the time has to exist in the base machine's account database (let's call it MACHINE1\MyAccount), which the remote machine (let's call it REMOTE) doesn't know about and won't be able to authorise to do anything at all.
The exception to this rule is that an account with
exactly the same name and password exists on both machines. If MACHINE1\MyAccount and REMOTE\MyAccount both exist, there is a crude hack in the workgroup security system that will invisibly convert an attempt to use MACHINE1\MyAccount into a use of REMOTE\MyAccount, so things work despite the fact that the machines don't have any trust relationship.
Where this tends to fail is when the account exists in both places, but with different passwords, as with e.g. "Administrator". If you ever use an account name like that, some subsystems and API sets will assume it belongs to the machine you enter it into (so, MACHINE1\Administrator) even if what you're doing is connecting to a remote machine.
The usual way you work around this to explicitly name the account on the remote machine, so in the connection dialog enter "REMOTE\Administrator" (or whatever the machine name is) instead of just plain "Administrator". If you do that, then the target machine will accept the credentials you use.
If that workaround doesn't help the remote client installation, let us know.