When working on a script this past week I came across a problem when trying to discover a servers domain when not being afforded access permissions. In my case my usual steps all came back with non-usable information.  All FQDN names were exactly the same for the computers on the our "test" domain as well as our "active" domain. All powershell scripts failed to run, due to my permissions, and without a major call to our service desk's API there seemed to be no other viable option for pulling this information. That's when I came across an older operation that fit the bill perfectly.

Nbtstat, according to Microsoft's technet library
is designed to help troubleshoot NetBIOS name resolution problems. When a network is functioning normally, NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses.
Long story short (this explanation doesn't seem short...I think you mean long story longer..I'm so clever -ed.) the TCP/IP stack doesn't understand "flat names" so Windows relies on an application called NetBIOS-Over-TCPIP (NBT) to handle them. When I refer to flat names I'm referring to the friendly names assigned to the computer aka Computer Name.

The NetBIOS-Over-TCPIP (NBT) "registers" the computers name upon Windows startup. This process makes sure that the computers name is unique and doesn't conflict with any other computers on the network. This registration process records this name in a WINS server on the network or by broadcasting the information out and waiting for other computers to complain that the name is being used. The NetBIOS-Over-TCPIP (NBT) also "resolves" other computers names to IP addresses to help with routing in the environment. For my needs it supplied me with the computers domain that I was searching for when running the command nbtstat -a [servername] (See Boxed content - ed.)

As with all things scripting you can easily find the entire list of variables for the command by running nbtstat -? 

This information can be used however you would like. For my purposes I used regular expressions and Powershell to pipe the information into a variable and used that to verified information for several different functions. 

I like to keep up to date with the latest Microsoft technologies and generally have a number of test environments running on my home computer. These test environments grant me the ability to create different "virtual" machines each with their own unique Operating Systems and programs without effecting my main computer. Recently, I had the opportunity to sit through a Window Server 2016 preview and thought I might like to get my hands on the new fledgling OS to see what I could glean from it. This is the first part of a multi part series running through the setup of a virtual environment on Windows 10 and the installation of Windows Server 2016 Essentials Tech Preview 3 on the newly established Hyper-V environment.

Since Windows 7 the "God Mode" folder has presented users with the ability to access all of their Windows settings in one central location. This "God mode" folder has an added benefit to Windows 10 users, however, as the operating systems settings have been divided into two sections: the traditional Control Panel and also in the new Settings menu. (NOTE: The below steps will work for Windows 7 machines as well - ed.)

Last week I was trying to verify whether one of my Windows client servers had been rebooted in order to take care of a check disk task I had set up to run on the servers next reboot. While a simple check for a winint task in my event viewer could have sufficed, I thought it would be fun to find another way around the problem (you can't just do things the easy way? - ed.). So being ever the overachiever I came across three other methods to check the last reboot time/uptime of my server in question:

When sitting in the cubicle today looking for a good way to script a rather monotonous task, I was presented with a lovely melody springing from my laptop speakers. "Greetings!" it chimed in rather overzealously for a Monday. "you may already be a winner of $100,000 dollars." As I scrambled to stop the traitorous noise I realized I had no way of knowing which tab it was coming from. Quickly I shut down Internet Explorer completely and slunk down in my desk hoping no one would peep over my cubicle wall to give me the evil eye. My next course of action was to go against office best practices and install my go to browser, Google Chrome.

Next PostNewer Posts Previous PostOlder Posts Home