Sometimes, I am too lazy to get up and turn my server/desktop on, when I am using my laptop. So I decided to enable Wake-On-Lan. The network adapter in my desktop will remain on and listen for a Wake-On-Lan Packet. When it receives that packet the machine will turn on. I remember back in the old days you just had to make one change in the bios to enable WOL, but now you need to make a few changes in windows 7/Server 2008 R2 in order to enable it.
There are many different BIOS’ and NICs, so unless you have the same motherboard as me, the changes you will need to make will probably be slightly different, but the process should be the same.
In my previous post I upgraded from Symantec Backup Exec 12.5 to Symantec Backup Exec 2010. I ran into a few problems during the upgrade process, including one that caused the nightly backups to fail. Here is the error in the backup job log:
Completed status: Failed Final error: 0xe0001201 – For this operation, the Backup Exec Virtual File Filter (VFF) driver must be installed on the media server. The VFF driver is installed when you install any of the following Backup Exec agents or options: Exchange Agent Active Directory Recover Option VMware Virtual Infrastructure Agent Microsoft Virtual Server Agent Final error category: Resource Errors For additional information regarding this error refer to link V-79-57344-4609
A client I was working with was having an issue with their Virtual Machine (VM) running on Hyper-V. It was an odd one that I have never seen before. The VM was running Server 2008 R2 and had a single synthetic Virtual NIC attached with a static IP. The problem was that when the VM was restored from a saved state, occasionally, the network would not work. This obviously caused issues for users that needed to connect to the VM via RDP. Luckily, this VM did not completely rely on the Internet, so minor downtime when the VM was restored from a saved state wasn’t a major issue. Disconnecting and reconnecting the NIC in Hyper-V did not fix the issue, and ipconfig /renew wouldn’t fix anything since the IP address was static. The only thing the admin was able to do to temporarily fix the issue (until the next saved state restore) was to log into the VM via Hyper-V console and disable and then enable the NIC that was having issues. Unfortunately, time was a factor in finding a solution, and I was unable to physically see the hardware or VM in action. This made it very difficult to figure out what was causing the issue in the first place. A workaround seemed to be a much better use of time than spending hours trying to deduce the problem via E-mail.
The restore action for the saved state was done by via script. So it would be very easy to tie in another script to essentially disable and enable the NIC after the VM was restored. From what I can tell, this can’t be done using the Hyper-V Powershell APIs from the host. Also, since the network was the problem, I couldn’t run a remote script from the host to fix the NIC. Anything that could be done would have to be done within the VM. Granted this is not a solution to the original problem, but a workaround, and given more time we would have looked into what the actual cause was. So, here is the workaround to the problem.
I was tweaking the editmessage.aspx page for OWA 2007 in Exchange 2007 and I noticed some leftover code comments from the developers at Microsoft.
Do code comments like this make it past the QA process often?
< !--LocalizedStrings.GetHtmlEncoded(Strings.IDs.SubjectColon)--> < !-- TODO: OWA: 775: make sure this comment (and any others) are removed in retail --> < !-- For some reason, if this input field is not wrapped in a div, when the user types some text it resizes itself by a few pixels. Go figure.-->
Windows 7 is a nice operating system and it has some pretty cool features. One of which, and one of my favorites, is that it comes with the newest version of Remote Desktop (RDP). This version is capable of letting you watch HD video through it (assuming your network connection is fast enough…). RDPing from one physical computer to another physical computer is easy and sound between the two works just fine. This is because both machines (most likely) have physical sound cards.
Sometime during my travels, I loaded Windows 7 onto a Virtual Machine (VM) running on Hyper-V Server 2008 R2. Virtual Machines in Hyper-V don’t have physical or even virtual sound cards like VPC. When RDPing to a Windows 7 VM the sound card is listed as Remote Audio. This is fine and will actually push through a decent amount of sound. While testing, it seemed to work fine for WMV files and a few other formats. For some reason, I was unable to get it to work with AVI files, and flash websites like youtube.com. I wanted full sound capabilities. So here is what I was able to get working.
I’m currently using Version 0.9.8 of WP-Syntax. I thought I would quickly go over its usage. To use WP-Syntax just switch over to HTML mode from Visual mode. The reason you need to do this is because Visual mode will escape out our <pre> code. Also, if your code contains any &, <, or >, you will need to stay in HTML mode for the rest of the post, otherwise if you switch back to Visual mode, some of your code could get double escaped and not work. (i.e. &, <, or >). It might be easiest to write your post and add the code at the end.
Writing your first PowerShell script can be pretty easy. Just open notepad and paste in:
Write-Host "Hello World!"
Save that as a .ps1 file and you’re are all set. That line will just print out Hello World! to the console.
Now, how do you run that script?
First, you open up Windows PowerShell. Browse to the location where you script is, and type the name of the script.
If this is your first time running a PowerShell script, chances are you will see an error message like this:
PS C:\Users\user\Desktop> .\HelloWorld.ps1
File C:\Users\user\Desktop\HelloWorld.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.
At line:1 char:17
+ .\HelloWorld.ps1 <<<<
+ CategoryInfo : NotSpecified: (:) , PSSecurityException
+ FullyQualifiedErrorId : RuntimeException
This is because PowerShell is pretty locked down to prevent unauthorized scripts from running.