Recently, Dell made some changes to their support website that broke the Dell Warranty Information Script. After investigating the changes, I determined that the new warranty information URL does not accept the service tag as a URL parameter, or at least it doesn’t appear to. Instead, the service tag is retrieved from a cookie that is generated when you enter the tag on this page. Good grief.
Scripting the cookies and passing them is probably possible, but I felt it was stretching the solution too far, so I adapted the script to use the undocumented SOAP web service instead. The script is below.
There are several things that I dislike about Dell’s AssetService web service:
It’s completely undocumented, and no one really knows what the guid and applicationName parameters are meant to do. I haven’t found anything indicating that it’s even a production service.
The descriptions returned for each entitlement (warranty record) aren’t as well formatted.
Sometimes, it doesn’t return the list of entitlements, so the script needs to be run again until it does.
When it comes to implementing power saving settings on managed workstations, the easy part is configuring the power management settings themselves. The hard part is ensuring that the systems remain consistently managed and maintained. Once standby settings are configured in Windows Power Management, idle workstations are likely to enter standby overnight, which is great way for conserving energy. But the evening hours are also an ideal time to deploy software and updates, because it’s less disruptive to employees that use these workstations throughout the day. How do you balance power savings, maintenance, and the end user experience on these systems?
Well, some people will tell you that Wake-on-LAN (WoL) is the solution. It’s true that, with WoL, you should be able to wake machines overnight to perform tasks — in theory at least. I say in theory because, any sysadmin that has tried to use WoL to wake and manage many workstations (100+) over multiple subnets will tell you that Wake-on-LAN is no magic bullet. There are several reasons for this:
To wake up a workstation with Wake-on-LAN, the workstation’s network adapter must be properly configured to receive WoL’s Magic Packets (trust me, these packets are much less magical than their name implies). This can be a lot more difficult than it sounds, especially if you need to script these settings for automated configuration.
In most environments, WoL packets will not work across subnets, so you need at least one device on each subnet that can send WoL packets. You’ll also need some sort of mechanism (usually software) to tell sender devices to send packets on their subnet to wake them up.
Many wireless network adapters do not support WoL, and the ones that do tend to have inconsistent results with receiving WoL packets. If you have workstations that only connect to the network via wireless, this is a problem.
If the workstation is disconnected from the LAN, the WoL packet won’t make it.
Scheduled Wakeups
WoL is very useful for many situations, especially for impromptu wakeups. But if you want your workstations to wake from standby at night, or any time, you may not want to depend soley on WoL. What you really need is something that tells Windows to resume from standby on a schedule. But how? Well, Microsoft Windows actually includes the capability to resume from standby at certain times. This functionality is a part of the Task Scheduler service, and it can be enabled by simply clicking a check box:
With the “Wake the computer to run this task” checkbox set on a scheduled task, the system will resume from standby at whatever time interval has been configured on the Triggers tab. It is important to note, however, that this won’t work if the system is completely powered off.
The next question is, what should the task do once it has woken up the system? The answer is, just about anything. For example, it could run a script that starts Windows Update, run a virus scan, or start a backup. If you can script it or call it from the command line, you can do it. Here’s a simple example of how you might keep the system awake for at ~10 minutes by using the ping command:
Scripting Wakeups
Alright, we can use a scheduled task to wake workstations. That’s great, but not very useful unless we can use a script to automate the creation of a task that does this. As you may already know, a scheduled task can be created with the command line utility: SCHTASKS.EXE. This is a relatively powerful utility for creating tasks, and once you understand all of the command line options, creating a task with this utility is fairly straightforward:
Unfortunately, it appears as though there’s no way to set “Wake the computer to run this task” via SCHTASKS. However, Windows Vista and 7 come with a robust Task Scheduler API that can configure this setting. I wrote a VB script that does just that:
' Name: ScheduledTaskSetWakeToRun.vbs
' Author: Matthew Boyd (iboyd.net)
' Date: 10/13/2010
' Purpose: Enables or disables the "Wake the computer to run this task" setting on Windows Vista and Windows 7 systems.
' It seems that in order to do this successfully, both in the GUI or via this script,the task compatibility
' mode must be set to "2.0" or else the setting gets reverted.
' Usage: cscript.exe ScheduledTaskSetWakeToRun.vbs "" [enable | disable]
' Example: cscript.exe ScheduledTaskSetWakeToRun.vbs "My Scheduled Task" enable
' The command above would set "Wake the computer to run this task" to enabled.
Option Explicit
Const TASK_UPDATE = &H4
Const TASK_DONT_ADD_PRINCIPAL_ACE = &H10
Dim TaskName, EnableWakeToRun, objTaskService, objRootFolder, objTask, objDefinition
If Wscript.Arguments.Count < 1 Then
Err.Raise 1, "Invalid command line arguments!"
Else
TaskName = Wscript.Arguments.Item(0)
End If
Wscript.echo "Task Name: " & TaskName
If Wscript.Arguments.Count < 2 Then 'Set EnableWakeToRun to true by default if enable/disable was not specified.
EnableWakeToRun = true
wscript.echo "Action: ENABLE 'Wake the computer to run this task'"
ElseIf UCase(Wscript.Arguments.Item(1)) = "ENABLE" Then
wscript.echo "Action: ENABLE 'Wake the computer to run this task'"
EnableWakeToRun = true
Else
wscript.echo "Action: DISABLE 'Wake the computer to run this task'"
EnableWakeToRun = false
End If
Set objTaskService = CreateObject("Schedule.Service")
objTaskService.Connect
Set objRootFolder = objTaskService.GetFolder("\")
Set objTask = objRootFolder.GetTask ("\" & TaskName)
Set objDefinition = objTask.Definition
wscript.echo "Current WakeToRun Setting: " & CStr(objDefinition.Settings.WakeToRun)
wscript.echo "Current Compatibility Setting: " & objDefinition.Settings.Compatibility
wscript.echo "---"
objDefinition.Settings.WakeToRun = EnableWakeToRun
objDefinition.Settings.Compatibility = 2
objRootFolder.RegisterTaskDefinition objTask.Name, objDefinition, TASK_UPDATE or TASK_DONT_ADD_PRINCIPAL_ACE, , , objDefinition.Principal.LogonType
Set objTaskService = CreateObject("Schedule.Service")
objTaskService.Connect
Set objRootFolder = objTaskService.GetFolder("\")
Set objTask = objRootFolder.GetTask (TaskName)
wscript.echo "New WakeToRun Setting: " & CStr(objTask.Definition.Settings.WakeToRun)
wscript.echo "New Compatibility Setting: " & objDefinition.Settings.Compatibility
To use this script, create a task first by using SCHTASKS. Then, run a command similar to this:
cscript.exe ScheduledTaskSetWakeToRun.vbs "My Scheduled Task" enable
The script will output both the previous and new values of the “WakeToRun” setting. You can verify that it worked by opening the Task Scheduler GUI and verifying that “Wake the computer to run this task” is set. This script can also be used to disable this setting.
You may also notice that the code in this script sets the “task compatibility mode” version to 2. I found issues with tasks that were using a different compatibility mode. It seems that “Wake the computer to run this task” would always be reverted, even if it was set through the Task Scheduler GUI. I believe the only disadvantage to changing the compatibility mode is that the task will not be backwards compatible with Windows XP.
By using a combination of Wake-on-LAN and scheduled wakeups, it’s much easier to successfully manage and maintain workstations in standby with better precision and accuracy. Also, by performing maintenance tasks overnight, you can keep workstations reliable without impacting the end user. It’s a win-win situation!
Recently, I encountered a strange issue after adding ATI Catalyst 10.4 Display Drivers to an offline Windows 7 image using the DISM.EXE /Add-Driver command. On systems that had an ATI Radeon video card, a UAC prompt would pop up the first time a user logged on and got to the desktop:
Important: Due to changes to Dell’s website, the script below no longer works. An updated script is available on this page.
Updated: 2/14/2012
This is a VBScript that I wrote a few months ago as an example of how to retrieve warranty information from the Dell website. The script writes warranty information to subkeys under HKLM\Software\DellWarrantyInfo in the registry.
Dell doesn’t provide a web service for querying warranty information (that I know of), so I had to scrape the HTML. That means this script may stop working properly if Dell makes changes to the layout of their warranty information page. I wish Dell provided a more reliable method for retrieving warranty information.
Update 1/3/2011: Thanks to Patrick for letting me know that dell added a new column to the warranty information table. I updated the script to reflect this.
As I’ve mentioned before, putting workstations into a low power standby mode when not in use is a great way to save money. Unfortunately, standby doesn’t always work like it should. Many sysadmins have struggled with applications, settings, and even system drivers that prevent standby from working reliably, or working at all.
There were many scenarios in past versions of Windows where workstations configured to enter standby after a certain period of idle time would refuse to do so, often without many clues as to why. This behavior is commonly (and cleverly) referred to as PC insomnia. While Windows 7 computers can still suffer from insomnia, the latest Windows OS now includes new tools and settings to troubleshoot and resolve it. There are a variety of things that may prevent a computer from properly entering standby when idle. Common reasons include hardware driver issues, service issues, and open file shares. Windows XP did not include any tools that could help pinpoint what was keeping the system awake, which often made finding the culprit a guessing game. Thankfully, the command line utility POWERCFG.EXE was updated in Windows 7 to include two new options that assist with tracking down insomnia issues.
If you haven’t already, you should check out my previous article about power management in Windows 7 in order to learn about power profiles and POWERCFG.EXE commands.
POWERCFG -REQUESTS
One way to troubleshoot Windows 7 insomnia issues, is the POWERCFG.EXE -REQUESTS command. This command can be used to display a list of applications and drivers that have made requests to prevent the computer from entering standby.
In the example above, there are actually two Windows components that are preventing the system from entering standby. The first issue is that Windows wants to keep this particular computer awake because a remote host is connected to a share on the computer . If this computer was acting as a network file server, that would probably be a good thing. But it’s not, so we either need to prevent the computer from sharing files at all, or allow it to enter standby regardless of whether a remote host is connected to a file share. The other issue is that Windows wants to keep this computer awake because it’s connected to a remote file share. While there are probably cases where this behavior is desired, I want Windows to enter standby regardless of whether or not the computer is connected to a remote network share. Otherwise, most workstations would never enter standby! Both of these issues can normally resolved by changing a few hidden power options, which is covered later in this article.
POWERCFG -ENERGY
In a some cases, it may also be useful run POWERCFG.EXE -ENERGY. This command performs a more thorough investigation in order find potential power management issues, such as those that may be preventing standby. When POWERCFG -ENERGY is run, it detects common issues by monitoring the system for a period of time and capturing system settings and events that may be preventing Windows power management from working properly. When done, the results are written to a HTML file.
By default, POWERCFG.EXE -ENERGY analyzes the system for 60 seconds. However, the analysis duration can be be set to a larger period of time to detect more sporadic events that are preventing standby. To perform an analysis for 10 minutes, run POWERCFG -ENERGY -DURATION 600. When finished, the results are written to energy-report.html, or the filename specified with -OUTPUT <FILENAME>.
While this report is more thorough that POWERCFG -REQUESTS, it may include items that aren’t necessarily related to issues with standby. For example, the report above shows the error USB Suspend:USB Device not Entering Suspend for several USB devices on this computer. While this may affect the computer’s power efficiency at some level, it’s not the reason that this computer was entering standby. In this case, the standby was being blocked by the System Required Request initiated by the driver \FileSystem\srvnet. This is related to the Windows network shares, and indicated to me that that standby was being blocked because a remote host was trying to connect to a share on the client computer. I wasn’t able to see this when running POWERCFG -REQUESTS alone.
Manually Checking Services
If neither of the tools mentioned above help pinpointthe cause of insomnia, you may want to try manually verifying that Windows Services aren’t preventing standby. This troubleshooting method is simple, but a bit tedious:
First, go to Start > Control Panel > Power Options and configure the current power profile so that the system enters standby after 1 minute.
Go to Start > Control Panel > Administrative Tools > Services. Sort the services by the status column.
One by one, stop services that are running. Each time you stop a service, let the computer idle for at least 2 minutes to see if it enters standby. Continue doing this until the computer enters standby. It’s probably best to begin with non-Windows services.
If/when the computer finally enters standby after you’ve stopped a service, make note of that service. Restart the computer so that all services are running again. Stop that particular service again and wait for the computer to idle into standby.
If the computer idles to standby, you have found the service that is preventing system standby.
What services could be causing insomnia? Some anti-virus applications have been known to prevent the system from entering standby for various reasons. Older or poorly-written services may also be the cause of PC insomnia.
Treating Insomnia
Windows 7 includes several power settings that may be useful for resolving PC insomnia. Interestingly, some of them are hidden and must be enabled in the system registry. Below are some common settings and methods for treating insomnia.
Allow Standby with Remote Opens
By default, Windows 7 will attempt to prevent system standby when connected to a a remote share or file. Presumably, this is to prevent any ongoing file transfers over the network from failing due to the system unexpectedly entering standby. But there are many cases where the system is connected to a remote share and it is okay to enter standby. Windows 7 includes a setting to allow the computer to enter standby, but it may be missing from the advanced power options dialog box. This .reg file will unhide the “Allow sleep with remote opens” option AND set it to Yes for three default power profiles (Balanced, High Performance, and Power Saver) in Windows 7:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d]
"Attributes"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d\DefaultPowerSchemeValues\381b4222-f694-41f0-9685-ff5bb260df2e]
"ACSettingIndex"=dword:00000001
"DCSettingIndex"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d\DefaultPowerSchemeValues\8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c]
"ACSettingIndex"=dword:00000001
"DCSettingIndex"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\d4c1d4c8-d5cc-43d3-b83e-fc51215cb04d\DefaultPowerSchemeValues\a1841308-3541-4fab-bc81-f71556f20b4a]
"ACSettingIndex"=dword:00000001
"DCSettingIndex"=dword:00000001
Although the registry entries above will configure the three default power profiles, it won’t apply the settings to custom power profiles. To do that, you’ll need to find the Power Scheme GUID of the power profile you created by using POWERCFG.EXE /LIST and then run these commands:
If the system is configured with file or media sharing enabled, Windows 7 may prevent the system from entering standby while users are connected to files or shares hosted on the system in order to prevent file transfers from being interrupted. Sometimes, media, file, and printer sharing may be enabled on the workstation without the user or the sysadmin knowing it. To make matters worse, there are some network applications installed that tend to scan network shares at regular intervals, which may prevent standby.
This behavior can be disabled by setting “When sharing media” to “Allow Computer to Sleep” within the advanced settings of a power profile. The setting shouldn’t be hidden by default. To apply this setting to a custom Windows 7 power profile, these commands can be used:
While applications can request that Windows to keep the system awake, that doesn’t mean that the OS should always listen. Applications make power requests like this for several reasons. For example, Windows Update may make a request keep to computer awake while updates are being installed or a reboot is pending. It’s actually very easy to implement a power request that blocks standby, which means it could be abused by a service or process that thinks it knows what’s good for it. If the results from POWERCFG -REQUESTS or POWERCONFIG -ENERGY show that a particular service or process is making a lot of unnecessary power requests, there is a way in Windows 7 to ignore those requests. To learn more about overriding a power requests, browse to the “Overriding a Power Request” section of this Microsoft paper.
Don’t Allow System Required Policy
If you’ve tried everything but still can’t get that insomniac system to enter standby when idle, there is one last setting that you can use in a last ditch attempt.
However,the “Allow System Required Policy” power setting may also cause Windows to ignore valid requests to keep the computer awake. Therefore, this setting should only be used if nothing else works and you’ve tried using a Power Request Override to ignore specific drivers, processes, and services. This registry entry will unhide the setting:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\A4B195F5-8225-47D8-8012-9D41369786E2]
"Attributes"=dword:00000000
To disable power request overrides for a power profile, these commands can be used:
Another common issue with Windows systems that enter standby is PC Narcolepsy. PC Narcolepsy refers to a behavior of the Windows Operating System, where a computer that resumes standby from a Wake-on-LAN (WOL) or scheduled wakeup event will enter standby again after 2 minutes unless there is user interaction, such as pressing a key on the mouse or keyboard. In Windows XP, there wasn’t any way to change this behavior. Fortunately, Windows 7 introduces a new power option that can change the amount of time that the computer resumes from standby: System unattended sleep timeout. However this setting is hidden in the power profile by default. Why is it hidden? I’m not quite sure. Perhaps because it could be confused with the standby timeout setting. It can be unhidden using this reg file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\7bc4a2f9-d8fc-4469-b07b-33eb785aaca0]
"Attributes"=dword:00000000
Once unhidden, this setting will be visible in the advanced power options dialog. However, most sysadmins need a way to automate the configuration of this setting. Like several of the settings above, this can be done if you know the GUID of the power profile that you want to set this setting on:
POWERCFG.EXE /SETACVALUEINDEX <POWER SCHEME GUID> 238c9fa8-0aad-41ed-83f4-97be242c8f20 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 <DURATION IN SECONDS>
POWERCFG.EXE /SETDCVALUEINDEX <POWER SCHEME GUID> 238c9fa8-0aad-41ed-83f4-97be242c8f20 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 <DURATION IN SECONDS>
Between Windows XP and Windows 7, Microsoft made significant changes under the hood to power management in order to make Windows a more energy efficient OS. While Windows Vista included a significant number of changes to power management, it really seems like Microsoft put much more effort into making Windows 7 more power efficient after complaints about terrible battery life with Windows Vista. This PDF provides a general overview of these changes. Many of the changes work out of the box, which is great for overworked sysadmins. However, there are a few settings that need to be configured as needed, particularly when it comes to system idle and standby settings. With Windows 7, Microsoft has included several additional features and troubleshooting tools that address some of the headaches caused by power management in Windows XP.
Standby Me
Before we dive into the guts of power management in Windows 7, let’s discuss the value of taking the time to configure power management settings. Since going green is a hot trend right now, many companies are starting to put pressure on sysadmins to find ways to squeeze power savings from a major offender to the energy grid: Computers. At many companies, workstations are left running 24×7, even when not in use. If the work week is only 40 hours, that means that many of these computers are in a Powered On with Nothing to Do (POND) state for 100+ hours per week. As Ford recently discovered, turning computers off when they are not in use is a great way to reduce energy waste and save some serious coin!
One disadvantage to turning off computers completely when not in use is that, when a user needs to use the computer again, they have to wait for the computer to start up, then log in, then load applications and documents again. Admittedly, this a bit time consuming and frustrating for an end user. Therefore, many sysadmins opt to put computers into a low power standby mode as a fair compromise between user experience and energy savings. Standby mode, which powers down most system components as suspends the system state to RAM, allows the user instantly resume where they left off when they last used the computer. In modern computers, standby only consumes slightly more power than when in a powered off state.
Applying Settings with POWERCFG
If you’ve used the POWERCFG utility in Windows XP, you’ll probably find one major difference in Windows 7: GUIDs. In Windows XP, a power scheme could be configured by specifying the name of the scheme in the POWERCFG command line syntax. In Windows 7, that is no longer an option. Instead, you must specify the GUID associated with a particular power scheme when configuring and activating a scheme. While POWERCFG in Windows 7 still includes a way to change the monitor, disk, and standby timeouts of the active scheme, it takes some understanding of the Windows 7 power management GUIDs to do anything beyond that. Not only are the power schemes themselves identified by GUIDs, Windows 7 uses GUIDs to uniquely identify settings and groups of settings as well. While the idea of working with GUIDs may seem like a daunting task, it’s actually pretty easy to wrap your head around once you know how to find and use these GUIDs.
The most straightforward way to get a list of power scheme, group, and setting GUIDs is to run POWERCFG -QUERY. As a side note, this command tends to generate a lot of output, so it may be wise to pipe the output to a file like this:
POWERCFG.EXE -QUERY > powercfg.txt
After running the command, the current directory should contain the powercfg.txt file with the output from POWERCFG – QUERY inside of it. Here’s what it looks like:
As you can see from the example above, POWERCFG -QUERY provides very detailed information about every power scheme and setting set in power options in a nicely indented format. At the top is the GUID associated with the power scheme (High Performance). Directly below that is the GUID that identifies the first subgroup of settings (settings belonging to no subgroup). The GUIDs that identify each setting are directly below that, with information about possible setting values.
Example
Let’s say we wanted to change the setting Require a Password on Wakeup to No within the High Performance power scheme. First, we need to use the output from POWERCFG -QUERY to find the associated GUIDs and setting index:
These values are then plugged into commands POWERCFG -SETACVALUEINDEX and POWERCFG -SETDCVALUEINDEX:
As you may have guessed, the first command affects the computer while it’s plugged in. The second affects the computer while on battery. There’s a few things that have been implied in this example, but are worth covering in case you plan to script power settings for a fleet of computers:
Windows includes three built-in power schemes: Balanced, High Performance, and Power Saver. These schemes are identified by the same GUID on every Windows 7 computer.
The GUIDs that identify subgroups and power settings are the same on every Windows 7 computer.
Several posts ago, I promised to provide some insight on the new development capabilities for SharePoint 2010 within Visual Studio 2010. Yeah, I’m still working on that. However, I did get around to installing and test driving Office Web Applications on top of SharePoint foundation and I have to say that I am quite impressed so far.
In recent years, it has become evident that Microsoft needs to port their office suite to the Word Wide Web in order to compete with Google Apps. For Office 2010, Microsoft has stepped up to the challenge by releasing a free online Office suite, appropriately named Office Web Applications. Despite being a bit rough around the edges, the applications provide an excellent idea of what direction Microsoft is headed in, and it certainly looks good.
The Word Viewer Web App provides a read-only version of the Word document inside of the browser.
In my opinion, there’s one huge advantage that Microsoft has over some (but not all) of the other competitors in the Online Office Suite market: Organizations have the option to host the Office Web Applications themselves. For organizations that can’t or don’t want to use a hosted solution, this could be huge. To get there, Microsoft has married the document management capabilities of Microsoft SharePoint with the new functionality that the Office Web Applications offer. As a system administrator, you must play the role of the priest in this wedding: Getting the Office Web Apps functionality requires a separate installation from SharePoint. The good news is that installing Office Web Apps feels relatively painless. As for the benefits? Well, imagine opening a Word document in SharePoint without ever opening Microsoft Word. Now imagine editing that document and saving it back to SharePoint without ever opening Word or even leaving your web browser. Daddy like.
From both an interface and functionality perspective, SharePoint and Office Web Apps integrate fairly well. By default, the Microsoft Word Web App opens documents in a read-only view. With this view, documents are displayed almost identically to how they look within the installed version Microsoft Word. Most text can be selected and copied to the clipboard. It’s like viewing a PDF document in a browser, but without the terrible Adobe Reader browser plug-in.
So how does the Word Web App do at actually editing documents? Well, it provides a lot of great functionality, but it does leave something to be desired. A familiar ribbon is displayed at the top of the page, with basic tools for formatting text, inserting pictures, and creating tables. Just don’t expect all of the special features that you’re used to seeing in the installed version of Word. It is free, after all. A few of the documents I tested did not have certain formatting settings that were visible in the online editor, such as table backgrounds. I’m not surprised by that. Overall, I see this as a great way to generate quick documentation or take notes, but I wouldn’t recommend it for advanced publishing. In fact, I wouldn’t recommend any of the online document editors for advanced publishing. They just aren’t that robust.
The Word Web App provides a lot of basic document editing functionality. Just don't expect to do a mail merge through it.
One of the most significant features (if you want to call it that) of the Office Web Apps is that they work across browsers, just like SharePoint 2010. This has always been a huge pain point for me with SharePoint 2007 and a few other Microsoft web products, because they have traditionally catered to Internet Explorer, and I am a Firefox user. There is also better support for viewing SharePoint sites and Word documents from mobile devices. I’m glad that culture at Microsoft has shifted such that they realize that cross-browser (and cross-platform) support will be crucial to their success in the future and I hope they continue down that path.
I haven’t had a chance to try out the Excel Web App, or the PowerPoint Viewer. I’ll save those for another weekend. Some good news for those waiting for the production version of SharePoint and Office 2010: Microsoft just announced that these products will launch on May 12, 2010 and RTM sometime in April. It will be interesting to see if there are any new features between the Betas and the RTMs. Regardless, I’m really looking forward to the latest iteration of these products.
If you’re looking for more information about Office Web Applications, be sure to check out the Office Web Apps blog on MSDN: http://blogs.msdn.com/officewebapps/ .
You’ve upgraded your web server to Windows 2008 and you have a bunch of Windows Vista and Windows 7 clients connecting to an ASP .NET application on that web server. The application uses My.Request.UserHostAddress to check the IP address of the client. For whatever reason, your application only expects an IPv4 address to be returned
Both the server and the client have IPv6 functionality enabled (by default) but are only configured with IPv4 addresses.
Since neither the client nor the server have an IPv6 address set, you would expect My.Request.UserHostAddress to return an IPv4 address. Instead, it returns an IPv6 address that starts with 2002 prefix.
How in the heck did this happen!? Well, it turns out that this behavior is by design. When Microsoft added IPv6 support beginning with Windows Vista, they added support for using IPv6 over an IPv4 network, for compatibility and transitioning purposes. By default, a Windows Vista or Windows 7 computer that only has an IPv4 address assigned to it will try to communicate over IPv6 by using a special IPv6 address called a 6to4 address. All 6to4 addresses start with the 2002 prefix. The good news is a 6to4 address is derived from the octets of an IPv4 address, so we can convert 6to4 addresses to their IPv4 equivalent. This Technet page goes into further detail about the 6to4 addressing scheme.
Here’s the code I wrote to convert 6to4 IPv6 addresses back to their IPv4 equivalent:
ipAddress = System.Net.IPAddress.Parse(My.Request.UserHostAddress)
If ipAddress.AddressFamily = Net.Sockets.AddressFamily.InterNetworkV6 Then '
Dim tmpBytes() As Byte = ipAddress.GetAddressBytes
If tmpBytes(0) = 32 And tmpBytes(1) = 2 Then 'Check it's a 6to4 address (it begins with "2002")
ipAddress = System.Net.IPAddress.Parse(Convert.ToString(tmpBytes(2)) & "." & Convert.ToString(tmpBytes(3)) & "." & Convert.ToString(tmpBytes(4)) & "." & Convert.ToString(tmpBytes(5)))
End If
End If
Note that this code will only be applicable to 6to4 IPv6 addresses. Normal IPv6 addresses will be ignored because they can’t be converted to an IPv4 equivalent. This means that your code will eventually need to handle IPv6 addresses if clients that connect to the application are ever assigned IPv6 addresses.
Although it may seem like most of Microsoft’s resources are tied up in the Windows 7 launch, you can rest assured knowing that MS developers have been hard at work on new versions of their enterprise products, including SharePoint. I created a Windows 2008R2 virtual machine with SharePoint Foundation 2010 (the lightweight version of SharePoint formerly known Windows SharePoint Services) to take advantage of all that extra RAM and CPU on my new Windows 7 desktop. After testing the beta, I can safely sum up the next iteration of this web-based content management and collaboration software in just one word: ribbon.
The tab-based toolbar that first appeared in Microsoft Office 2007 has now been tied in (pun intended) to SharePoint, most likely to further associate it with the Microsoft Office branding. It is by far the most obvious change in SharePoint and probably one of the best. It’s also a very crucial part of the new in-browser WYSIWYG editor for editing pages. Yes, it works in Firefox! Overall, the SharePoint 2010 interface is a huge improvement. Here are a few screen shots:
I’m investigating some of the new Visual Studio 2010 features for developing SharePoint 2010 content. I’ll have another post about that in the near future.
Sometimes I write code that I think I need but never end up using. This was the case with the parseCommandLineString() function that I wrote in Visual Basic .NET. I needed a function that would take a command line string that included arguments and parse it in the same way that Environment.ParseCommandLineArgs() does. Why? Because System.Diagnostics.ProcessStartInfo uses two properties that separate the executable file name from the arguments. Why Microsoft left this functionality out of the framework is beyond me. Anyway, there is a method build into the Windows API that can parse arguments from a command line string: CommandLineToArgv(). Unfortunately, calling it in VB .NET requires Marshalling and I couldn’t find a good example online. Here’s my code:
Private Declare Function CommandLineToArgv Lib "shell32.dll" Alias "CommandLineToArgvW" (ByVal lpCmdLine As String, ByRef pNumArgs As Integer) As Long
'''
''' Summary: Parse the command line string so that it can be used with System.Diagnostics.Process. I chose to use the Windows API here to ensure that the command line parsing is consistent with how Windows handles it.
'''
''' Parameter command: The string that should be parsed
''' Returns: An array of command line arguments similar to what Environment.GetCommandLineArgs() produces.
''' It sure would be nice if the framework had a method for doing this. It becomes a drawback of using System.Diagnostics.Process, which requires arguments to be separated from the executable.
Private Function parseCommandLineString(ByVal command As String) As String()
Dim numargs As Integer
Dim t As Integer
Dim ptrCommand As IntPtr = Marshal.StringToHGlobalUni(command) 'Marshal the string to a pointer
Dim ptrSplitArgs As IntPtr = CommandLineToArgv(ptrCommand, numargs) 'Pass the pointer to CommandLineToArgv for parsing, retrieve the pointer of the result.
If ptrSplitArgs = IntPtr.Zero Then Throw New System.ComponentModel.Win32Exception 'Is it a valid pointer? Throw an exception if it isn't.
Dim splitargs(numargs - 1) As String
For t = 0 To numargs - 1
splitargs(t) = Marshal.PtrToStringUni(Marshal.ReadIntPtr(ptrCommand, t * IntPtr.Size)).Trim 'Iterate through the arguments and add them to an array.
Next
Marshal.FreeHGlobal(ptrCommand)
Marshal.FreeHGlobal(ptrSplitArgs)
Return splitargs
End Function
The expressed opinions, informational content and links displayed on this website do not necessarily reflect a position or policy of The Pennsylvania State University or its affiliates.
Comments (33) ![[del.icio.us]](http://iboyd.net/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://iboyd.net/wp-content/plugins/bookmarkify/digg.png)
![[Facebook]](http://iboyd.net/wp-content/plugins/bookmarkify/facebook.png)
![[StumbleUpon]](http://iboyd.net/wp-content/plugins/bookmarkify/stumbleupon.png)
![[Twitter]](http://iboyd.net/wp-content/plugins/bookmarkify/twitter.png)
Themocracy