Cant use credentials with a space in the windows username
We have a networked domain which works great with PDQ, but we also have a group of 20 computers purposely not on a domain. I'm trying to get the credentials set up for those 20 machines in PDQ to use the local administer accounts on each of those machines as the credentials in PDQ.
BUT, my problem is that a previous tech here set up the local admin account on these 20 machines with a space in the username. After I set up the local admin credentials in PDQ Inv/Deploy, PDQ is failing to connect to these machines (though it sees them online). My example is I have a PC named 'MACHINE1' and the admin account is 'Stockpile Admin'.
To troubleshoot I'm cutting PDQ out of the mix and trying to navigate directly to a share: \\MACHINE1\C$ on one of these machines using a different computer and attempting to log in as User: MACHINE1\Stockpile Admin
That fails in Windows. I then tried in my login attempts to substitute the space with a period, dash, and removing the space completely. That didn't work. I also tried wrapping the the username in double quotes and single quotes. That also didn't work. I couldn't wrap the whole domain/machine name and username in quotes ("MACHINE1\Stockpile Admin" because windows then thinks that my domain/machine name began with a quote and my username had a quote char at the end of it.
QUESTIONS:
1.) Outside of PDQ, how the heck can I log in to a computer or map a drive using credentials that have a space in the username?
2.) Once question 1 is solved, how would I then apply that to PDQ?
Thank you.
Comments
I ended up solving this. In regards to Question #1, logging into a Windows administrative share, the issue is that by default Win7 only lets you log into the C$ and ADMIN$ administrative shares when using the actual Administrator account. In my case I had an admin account named something else that was in the Administators group, but that's not enough. It either needs to be actual Administrator OR do this registry edit: https://support.microsoft.com/en-us/kb/947232 OR there is a local security policy which you can edit.
As for my Question #2, once #1 was resolved, Q#2 was no longer an issue.
Glad to hear you were able to resolve this and thanks for sharing the answer for others Mike.