Bookmark and Share

In this post:

 

What Happened to the MSScript E-Mail Alias?

Hey, Scripting Guy! Question

Hey, Scripting Guy! I've tried to send you an e-mail about problems I was having with a script, but I got the failure notice shown below. I used the e-mail address that was linked from a WSC page on MSDN. This is rather strange.

> ================

> This is an automatically generated Delivery Status Notification.

> 

> Delivery to the following recipients failed.

> 

>       msscript@microsoft.com

> 

> ================

-- ME

 

Hey, Scripting Guy! AnswerHello ME,

Microsoft Scripting Guy Ed Wilson here. The e-mail alias msscript@microsoft.com no longer works. This is why you received the bounce back e-mail. If it had worked, it would have gone to the team that created the Windows Script Components or perhaps the team that develops VBScript or maybe the VBScript SDK team. I did a Bing search for the e-mail alias after verifying that it is no longer active at Microsoft, and I am currently trying to track down the owner of one of the pages that lists the e-mail alias.

So the short answer to your question is I’m not sure where it would have gone if the address where valid.

I can tell you that the TechNet scripting forums are a great place to ask questions and to receive answers from peers and members of the Microsoft Professional Support community. I have used these forums in the past, and not only are they a great way to get answers, but also they are a great way to make friends and professional contacts. It is tru, that some forums seem to have a few people that will attack others (a technique known as flaming), but in a well-managed forum, the forum moderators will take steps to control such behavior.

On the TechNet Script Center, we have The Official Scripting Guys Forum, which is a great place to get answers and to participate in discussions about VBScript and Windows PowerShell scripting techniques. People in the forums are great at answering questions. Someone might even write a script for you. It is a great place to hang out, and I myself have a forum ID and often join in the discussions because it is so much fun.

I sincerely hope this is helpful for you. I personally do not have source code access (nor do I want the responsibility of source code access) and therefore would not be very good at troubleshooting your bug. If you are facing a bug in the product, it is best to open a support case with Microsoft Premier Support because  they are the ones who track and fix bugs.


 

How Does the Clear-EventLog Cmdlet Work? 

Hey, Scripting Guy! Question

Hey, Scripting Guy! I just read about some of the cool new features in Windows PowerShell 2.0 that support Event Viewer. Of special interest is the Clear-EventLog cmdlet. Is there a parameter with this cmdlet that backs up the logs before the entries are removed? If so, how does it work?

 

-- ST

 

Hey, Scripting Guy! AnswerHello ST,

No. Here are the cmdlets that work with classic event logs in Windows PowerShell 2.0:

PS C:\> Get-Command -Noun eventlog

 

CommandType     Name

-----------     ----

Cmdlet          Clear-EventLog

Cmdlet          Get-EventLog

Cmdlet          Limit-EventLog

Cmdlet          New-EventLog

Cmdlet          Remove-EventLog

Cmdlet          Show-EventLog

Cmdlet          Write-EventLog

 

I did write a script during Event Log Week that backs up and then clears the event log. The post it is in is called How Can I Check the Size of My Event Log and Then Back Up and Archive It If It Is More Than Half Full? Quite a mouthful.


 

How Do {Get;Set;} Properties Work in Windows PowerShell? 

Hey, Scripting Guy! Question

Hey, Scripting Guy! I am finally hunkering down and learning Windows PowerShell, and I am slowly growing to love the whole model and the object-oriented pipeline. Windows PowerShell is great stuff. But when I see methods, I want to invoke them. I have tried many things such as:

 (some object).methodname()

 

When I see {get;} properties, I want to be able to retrieve them, and I can use syntax like this and retrieve the value:

(some object).propertyname

 

But when I see {get;set;} properties, I want to modify them, but I can't unless someone's gone to the trouble to write some Set-blahblah cmdlet that refers to the particular property on the particular object type. Why isn't there a cmdlet called Set-Property that looks something like this:

(some command that emits objects) | Set-Property -propertyname color -value "Green"

 

The Windows PowerShell interpreter would then look at the datatype offered by -value, check that it's plausible for the property named Color (and check that it's a {get;set;} rather than a {get;}), and then change the Color property on any and all objects that arrived on the pipeline? I suppose it would then shoot something down the pipeline, probably a copy of the modified object? Something like this:

get-person -name MarkM | set-property -propertyname eyecolor -value "Purple"

 

I ask because—and perhaps I'm missing something big here—there must be a reason that {get;set;} properties exist. Why not let me directly modify them?

 

-- MM

 

Hey, Scripting Guy! AnswerHello MM,

I would imagine you are playing around with WMI inside Windows PowerShell. Because WMI is abstracted when it reaches Windows PowerShell, all of the properties come back as saying they are {get:set;} in Windows PowerShell. This is illustrated here:

PS C:\> $a = Get-WmiObject win32_bios

PS C:\> $a | Get-Member

 

 

   TypeName: System.Management.ManagementObject#root\cimv2\Win32_BIOS

 

Name                  MemberType   Definition

----                  ----------   ----------

BiosCharacteristics   Property     System.UInt16[] BiosCharacteristics {get;set;}

BIOSVersion           Property     System.String[] BIOSVersion {get;set;}

BuildNumber           Property     System.String BuildNumber {get;set;}

Caption               Property     System.String Caption {get;set;}

 

Now I am going to change the caption by using the “setter” of the property:

PS C:\> $a.Caption = "MrEd Waz Here"

PS C:\> $a.Caption

MrEd Waz Here

PS C:\>

 

The problem is that this only modifies the object that is currently in memory and not the actual BIOS that is represented by the WMI Win32_Bios class.

However, for regular .NET Framework class objects such as files, we can make actual changes to the objects via the setter. For example, we can {get;set;} the LastWriteTime property of a file. This is seen here:

LastWriteTime     Property   System.DateTime LastWriteTime {get;set;}

 

The LastWriteTime property is a System.DateTime data type, which we can retrieve from the Get-Date cmdlet. First, let us see what the actual LastWriteTime of the object is:

 

Now let’s change it:

PS C:\> $a.LastAccessTime = (Get-Date)

PS C:\> $a.LastAccessTime

 

Saturday, August 22, 2009 6:13:01 PM

 

However, we have been lied to before, so let us look:

Image showing that the property was changed

 

As you can see, the property was in fact change, and it worked exactly as we expected it to. If a property can be modified, the setter will allow you to modify the property. If the underlying object is not exposed by the provider, you can still modify the object in memory, just not the underlying object.

 

Well, this concludes another edition of Quick-Hits Friday. It also concludes another exciting week on the Script Center. Join us next week as we delve into the mysteries of…

If you want to know exactly what we will be looking at on Monday, follow us on Twitter or Facebook. If you have any questions, send e-mail to us at scripter@microsoft.com or post your questions on the Official Scripting Guys Forum. See you on Monday. Until then, have an awesome weekend.

 

Ed Wilson and Craig Liebendorfer, Scripting Guys