By default, VMware virtual network adapters show up as an unidentified network with limited connectivity. This post discusses the underlying reasons and shows you how to resolve the problem either manually or using a Windows PowerShell script.
|
|
||
|
By default, VMware virtual network adapters show up as an unidentified network with limited connectivity. This post discusses the underlying reasons and shows you how to resolve the problem either manually or using a Windows PowerShell script. There was an early Christmas present from the Windows PowerShell (AKA PoSH) Team. The Community Technology Preview 3 (CTP3) of Windows PowerShell v2.0 was released on December 23rd just in time for Christmas. The announcement is here. As expected CTP3 builds on the new technology provided in CTP2 which was released in May 2008. You can download CTP3 from the Microsoft Download Center. Hemant Mahawar, Program Manager for PowerShell, summarized the CTP3 release as follows: This release brings, among other things, performance improvements … things will be faster/more efficient than before. PowerShell remoting now allows implicit remoting where command execution appears to be local even though they are remote. We have added over 60 new cmdlets in this release … cmdlets for adding/removing/renaming computers, cmdlets for event logs, cmdlets for WS-Man functionality and even a WS-Man provider. The “graphical” host, Windows PowerShell ISE, now supports a graphical debugger, context sensitive F1 help and a programmable interface for you to party on. I tested CTP3 on Vista Ultimate SP1. The only issue I encountered when installing CTP3 was that fact that CTP3 did not honor the execution policy set by me in CTP2 contary to what was stated in the Release Notes. Moreover, it was impossible to set the execution policy to unrestricted using Set-Executionpolicy. After digging around in the registry hives, the problem became apparant. The PowerShell execution policy is set correctly in [HKEY_LOCAL_MACHINE\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\executionPolicy] but not in [HKEY_CURRENT_USER\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\executionPolicy]. I found this registry entry had to manually changed from allsigned to unrestricted. One major enhancement in this release relates to remoting and background jobs. Both require that you install Windows Remote Management (WinRM) 2.0 CTP3. Currently WinRM 2.0 CTP3 is supported only on Windows Vista SP1 and on Windows Server 2008. For some reason that I do not yet understand background jobs, even the jobs only run on the local computer, rely on the remoting features of PowerShell. The othere major enhancement relates to what was known as Script CmdLets in CTP2. They have been renamed to advanced functions in CTP3. Advanced functions are functions that have the same capabilities and behaviors as cmdlets but are written using the PowerShell scripting language instead of a compiled language such as C#. There are two types of advanced functions, i.e. named functions and unnamed functions.  Both types use the CmdletBinding attribute to identify themselves as advanced functions that act similar to compiled cmdlets. Both types can also be used within a script file. The difference Microsoft’s PowerShell is radically different than shells on UNIX or GNU Linux systems in that Powershell can deal in objects rather than just plain text. A concrete example may help you more quickly understand the difference. Suppose you want to get and save information about all the files in a certain subdirectory. We want to get not only the names of the files but as much metadata as possible relating to each file such as date of creation, date of modification, etc. This information also needs to be stored in a single XML document. To keep the size of this post manageable, our subdirectory contains only two files, i.e. file.xml and file.xsl, as shown below. On a UNIX or GNU Linux system, this would be a somewhat difficult task to quickly accomplish. Using Powershell, however, it becomes a simple one or two line task. Because Powershell is fundamentally object-orientated, it regards a filesystem as being an object representated as a location exposed by provider. More generally, a location can be a file directory, a registry hive, a certificate store or some other “thing” exposed by a provider. The Powershell get-childItem cmdLet is used to retrieve information, including metadata, about items in a specified location. Thus get-childItem can be used for a lot of different types of operations including enumerating directory contents, listing registry values or showing the current values of variables. For our purposes, get-childItem exposes information about files in a specified subdirectory or the current directory if no directory is specified. Here is a single line Powershell script which does what we want to do. It retrieves metadata about the two files in the current directory using the get-childItem cmdLet, pipes that data to a cmdLet called ConvertTo-XML which in turn converts the metadata into a valid XML document. The save method is then used to write this stream out to a file called file.out in the current directory. (get-childItem | ConvertTo-XML -NoTypeInformation).save(“$(convert-path “X:”)\file.out”) Alternatively, we could store the retrieved metadata in a variable and then write it out to a file as shown below. Similar to bash and ksh93, Powershell supports the concept of aliases and defines ls as one of the aliases for the get-childItem cmdLet,dir and gci being the other two. $a=(ls | ConvertTo-XML) $a.save(“$(convert-path “X:”)\file.out”) Here is the contents of file.out. As you can see, quite a bit of information about each of the two files is exposed. <?xml version="1.0"?> <Objects> <Object Type="System.IO.FileInfo"> I am excited about the emminent release of Microsoft Windows Powershell Version 2 CTP3 (Community Technology Preview Version 3) which is due “real soon now.” The first CTP for Powershell 2.0 was in November 2007 and there has been a lot of progress on the product since then. See the permanant link at the side of my blog to access the Powershell developers blog. Why am I, a UNIX/Linux developer, excited by Powershell V2? After all it does not run on any UNIX or GNU Linux platform and microsoft has no plans to port itMto these platforms. The main reason is that Powershell V2 supports non-compiled functions (known as script cmdlets) in scripts just like bash or ksh93 does while providing deep object orientated interfaces to the operating system and underlying platform. Previously cmdlets had to be written in a compiled language such as C# or VB.NET in order to provide such functionality. (Currently, the terminology for what is generally know as a function in a UNIX/GNU Linux shell script is called a script cmdlet in Powershell but this is apparantly on track to change to function in CTP3.) Another reason is the introduction of a graphic interface to Powershell. I have spend more than 25 years of my life working on or with UNIX, UNIX-like or GNU/Linux operating systems. For a period of that time, I was responsible for maintenance and enhancement of various shells and hence still maintain an interest in this area. Much progress has occured in UNIX/GNU Linux shells over that period of time with bash, zsh and ksh93 emerging as the de facto leaders and csh, tcsh, sh (as in the Steve Bourne shell) and ash slowly fading away into obscurity. Standardization of functionality for portable shell scripts has moved from simply “use the Bourne shell if you want your script to run everywhere” to written specifications such as POSIX which all three shells support. Numerious attempts (dtksh, Wksh, tksh come to mind) have been made to develop shells with graphical interfaces but none has been really successful. Currently work is afoot to provide deeper interfaces into the operating system and platform with the latest versions of ksh93 having support for compiled builtins, compound variables and quasi-objects (which I plan to write about soon in another post.) While it may be tantamount to heresy to say this, but kudos to the Microsoft Powershell development team who have managed in my opinion to leapfrog all the |
||
|
Copyright © 2005-2012 Finnbarr P. Murphy. All Rights Reserved. |
||