‘There are no logon servers available’ – Rebuilding AD Laptop Remotely With VPN

June 11, 2013 by Leave a Comment

vector_displayA recent upgrade to my work laptop (replacing the standard SATA 250GB drive with a super fast 256GB OCZ Vector SSD) prompted me to rebuild my OS with a fresh copy of Windows 7 Professional x64.

As you would expect, my work laptop is domain connected, so my main user profile is within the domain – but only being in the office very infrequently meant that I was actually building the new Windows instance at home away from the domain. Here was the rub: laptop needs to be domain connected to restore a domain profile – but I’m at home and the AD servers are remote and require a VPN. Also, once restored, the domain account cannot authenticate to a remote AD server without a VPN connection, but the VPN isn’t available until after first successful login. Chicken & Egg. Bugger!

What you don’t want to do is drive 100 miles to the office, just to connect to the wire that will allow your credentials to cache correctly – there MUST be a better way. Luckily, there is!

I decided to use the ‘Windows Easy Transfer’ application to backup my laptop profiles to an external USB drive instead of using a SATA drive cable and a clone technique. I’ve had issues with cloning drives before, and this was probably as good a time as any to do a little housekeeping on my OS instead of porting all the rubbish that accumulates over time. Here was the process I followed, to restore my domain connectivity and profile:

  1. Use the Windows Easy Transfer to make a backup of all the local profiles and shared items on the laptop that are needed to be ported to the new drive.
  2. Remove the old drive, then install the new SSD drive per the manufacturers instructions.
  3. Install a new copy of Windows to the new SSD drive.
  4. Create a new local administrator account as part of the Windows installation.
  5. Create a new VPN connection to your domain, using whatever method is required by your VPN provider.
  6. Join the new OS to the AD network (My Computer > Properties > Network Settings > Network ID), using a domain account with domain-joining permissions.
  7. Reboot the OS.
  8. Login to the new local account, and add your AD domain account to the Local Administrators group.
  9. Reboot the OS.
  10. Use Windows Easy Transfer to restore the profiles and shared settings backed-up in Step 1 above.

Once this is complete, your domain account and all information and settings will have been restored to your new SSD drive. If you try and login to the domain account however, this will result in the ‘No logon servers are available’ error message, as your profile will not have any cached credentials with which to authenticate to the domain.

  1. Login to the local account, and establish the VPN connection to the remote domain as in Step 5 above.
  2. Once connected, either hit Ctrl+Alt+Del or Start > Switch-User to re-authenticate the next user whilst the VPN is still connected.
  3. Login to the remote domain account, and the VPN connection will remain active long enough to authenticate the domain account with the remote AD domain – this process will also create a set of cached credentials to allow login to the domain account without a VPN connection.

I created this quick KB using a SonicWALL VPN client, but have tested it with other VPNs (including vCloud Director / vCNS Edge) and that works too.logo_Dell-SonicWALL-footer

Filed Under: Howto, Networking, Software, Windows Tagged With: , , ,

vSphere ‘Invalid configuration for device ’0′ error’ Solution

April 19, 2013 by Leave a Comment

Using vSphere 4 hosts (in this case a legacy un-patched host that was being migrated off and decommissioned), we came across an interesting and ambiguois error – ‘Invalid configuration for device ’0′, plus a note of time, the target object and the vCenter Server.

In this case, I was trying to migrate a powered-off VM to different storage – resulting in the error. I also found that the issue was related to the second disk attached to the VM. Editing the VM showed the size as 0MB, but removing this disk also threw the error in vCenter.

The solution was to follow these steps:

  • Remove the VM from the vCenter inventory.
  • Update the VM VMX file. There are 2 ways to do this – SSH to the host / datastore using a tool like Putty, or use the datastore browser to download the VMX file, then edit the it in Notepad.
  • Inside the VMX file. look for the following entries:

scsi0:1.present = “true”

scsi0:1.fileName = “vmname.vmdk”

Update these entries to the following:

scsi0:1.present = “false”

scsi0:1.fileName = “vmname.vmdk”

  • Re-add the VM to the vCenter inventory, either through the GUI or using ‘vmware-cmd -s register \path\to\your\vm.vmdk’.
  • Check the VM properties, you should now show the offending drive as missing and it can be re-added from the datastore.
Filed Under: Howto, Software, VMware, vSphere Tagged With: , , ,

Windows 2008 R2 Domain Trust – Fixing The Security DB Trust Relationship

April 16, 2013 by Leave a Comment

I came across an interesting problem recently. A customer is trialling child DNS domains for their server in their lab set-up, and we came across an interesting problem when changing the FQDN of the server.

In this instance, we were playing with using dcpromo to promote and demote the domain controller (DC) into a single domain. At one point, we got out of step with the reboots and got the following message when logging-in to the domain:

The Security database on the server does not have a computer account for this workstation trust relationship.

Interesting. Somehow, we managed to get the domain out of sync with the FQDN of the server. We found 3 ways to resolve this issue, 2 simple (which felt a little like a hack) and 1 that permanently fixed the issue:

  1. Login to the DC with local admin credentials, and in Computer / Properties: change the FQDN.local name to just the machine name, then reboot the server.
  2. Update the DC FQDN in the domain DNS system, so the current DC FQDN and that in the DNS server match.
  3. Update the computer account in the domain to reflect the FQDN of the DC. To do this:
    1. Open your domain Users & Computers console.
    2. Under View, select Advanced Features.
    3. Find the computer account of your DC. (Depending on what your policy is, this might be under <AD Host> / <Domain> / Domain Controllers, or elsewhere in another OU. If in doubt, use the domain search for the machine name, or ask the domain admin!
    4. Open Properties of the computer account, then select “Attributes Editor”. (If you can’t see it, re-check step 2 above).
    5. Look for attributes “dNSHostName” and “servicePrincipleName” (and anywhere else the FQDN of the DC is found).
    6. If incorrect (they should be – to produce the error on the DC), update them to the correct values.
    7. Reboot the DC and try connecting again. If the error persists, re-check the attributes in step 5 again for any missed values that need resetting. Also bear in mind that the DCs may need some time to replicate if your domain has more than one DC.

Also worth pointing out that these errors don’t always require a reboot, so if you are doing this under a change window or are limited for time then it’s possible the fix will be applied fine without a reboot. But then hey – your DCs are all virtual, so will reboot in about 10 secs anyway. Right?

Filed Under: Howto, Networking, Software, Windows Tagged With: , , , , , , ,

Google Reader RIP, Should I Care?

March 14, 2013 by Leave a Comment

Yesterday, Google announced that as of July 1st 2013 they are retiring the Google Reader service. It was one of several stories that caused some bloating of my twitter timeline as scores of people that I follow picked up on it.

My initial reaction was not a good one. I started using Google Reader only a few years ago but it has become a trusted and valuable way for me to consume information and news from the industry that I work in. Its absence will have a considerable impact on my daily activities.

Having slept on it though, I’m certainly a lot more relaxed about it. Yes, it’s going to have an impact but have Google actually just provided me with a catalyst to change the way that I consume information? I mean, I could easily just swap to using another service. Feedly, for example, even have processes in place to allow you to migrate from Google Reader (something that may have contributed to their site being incredibly slow last night after the Google announcement broke). But does Googles decision point towards a trend of moving away from RSS? What then is the alternative way of reading updates from the various sites and feeds that I have been following?

I don’t have a clear answer to any of these questions just yet but I’m going to be thinking about alternatives now. In the short term, moving my collection of feeds to another service seems to be the logical thing to do. After all, that’s one of the benefits of cloud services - portability. It will only be the work of a few minutes and I can carry on reading my RSS feeds on any of my devices beyond the end of June.

Filed Under: Cloud, News, Opinion, Software Tagged With: , ,

Fixing vCloud Director ‘HTTP NFC Error’ & Sysprep

February 6, 2013 by Leave a Comment

Recently I’ve been doing some work on vCloud Director deployments, typically new VMs within Organisations.

On powering-on VMs or deploying vApps, I got the error ‘Unable to start vApp ‘<vApp Name>’. The more specific error related to one or more of the following errors:

  • ‘HTTP NFC Error’. Cannot deploy package from /opt/vmware/vcloud-director/…. etc etc.
  • Unable to start vApp.
  • Unable to start virtual machines in resource pool.
  • Broken pipe.
  • java.net.SocketException: Broken pipe.

http-nfs-error

Solution:

A little bit of digging on the vCloud cell (RHEL in this case) showed the permissions were incorrect on the ‘guestcustomization’ folder, and that changing these fixed the problem. A little more investigation showed-up the following VMware KB article from 2011 confirming which permissions to reset and the commands to use: http://kb.vmware.com/kb/2004364. (Interestingly, it wasn’t the HTTP NFC Error that led me to this KB, rather the java.net error above.

Anyway – using the permissions listed in the KB solved the issue.

Filed Under: Cloud, Howto, Software, vCloud Director, VMware Tagged With: , , , ,
«Older Posts