The use of automation to deploy and manage complex TCP/IP networks is of prime importance to just about any IT Pro these days. It’s hard to think of how some businesses would function without a working network, including Internet and IP phone access. Even mid-size companies can find their networks are becoming more complex with each passing year as requirements grow for network services – and Lync can certainly provide the need for those services!
In terms of managing your TCP/IP network, PowerShell and the PowerShell modules released with the latest versions of Windows are slowly slowly replacing tools that have been in use since Windows NT launched over 20 years ago and before then on Unix (e.g. IPConfig, Ping) and well as somewhat more modern ones such as NetSH.
For the Lync Admin, these tools and the PowerShell cmdlets replacing those older tools both enable you to perform the same operations (e.g. check that the SRV record for your pool is correctly registered). You’re just using different tools (and with some judicious cmdlet aliasing, can be more efficient that the older tools!). This is the first of a number of articles I’m going to write this year focusing on managing networks using PowerShell V3 and Windows 8.
In writing scripts to configure any aspect of a Lync network (IP address, DNS settings, routing information, etc., etc.) you need to be able to enumerate and then select specific network objects (NIC, Route Table Entry, DNS Cache objects). To simplify the management of these objects, you need a simple and consistent object naming convention and the ability to name specific objects based on this naming convention. This involves writing some simple configuration scripts.
One challenge to doing this has been the default naming convention used before Windows 8. But with Windows 8 and beyond it’s much simpler. If you just one NIC, it is named either Ethernet or WiFi. If you have a second, or third NIC, it would just have an integer appended to the name, e.g. Ethernet 2, Ethernet 3 etc. A nice special case is the pseudo NIC added to the Hyper-V host representing a Hyper-V Switch. These are named vEthernet (<switch name>).
My Hyper-V host looks like this (and apologies for the rendering here in the blog):
[cookham12]: PS C:\Users\tfl\Documents> get-netadapter
Name InterfaceDescription ifIndex Status MacAddress LinkSpeed
---- -------------------- ------- ------ ---------- ---------
vEthernet (External) Hyper-V Virtual Ethernet Adapter #3 27 Up 00-1E-4F-CC-26-21 10 Gbps
vEthernet (Internal) Hyper-V Virtual Ethernet Adapter #2 16 Up 00-15-5D-01-77-00 10 Gbps
Ethernet Broadcom NetXtreme 57xx Gigabit Cont... 12 Up 00-1E-4F-CC-26-21 1 Gbps
This naming convention is provided for you when you install Windows and add NICs (virtual or otherwise) and gives you a great starting point. Most IT Pros will want to name individual NICs with a more task oriented name (e.g. VPN1, SIP-PROV-GC-<city>-<linkid>, etc). Your PowerShell script to name these NICs might look like this:
Get-NetAdapter | Where name -like *vEther*External* |
Rename-NetAdapter -NewName "SIP-PROV-GC-LON-1"Get-NetAdapter | Where name -like *vEther*Internal* |
Rename-NetAdapter -NewName "VM"
In some future articles, I’ll look at how to take this consistent naming system and perform common configuration and troubleshooting on them.
No comments:
Post a Comment