Does this make any sense?

So today the nytimes website went down.  The Syrian Electronic Army are being blamed.  Can we work out who they are and how they accomplished this?

If you ping http://www.nytimes.com the IP address comes up as 141.105.64.37.  A whois on this IP address shows that it’s in the IP range owned by Shorefront Media, Inc addressed in Moscow (reference – http://whois.domaintools.com/141.105.64.37).

A reverse IP lookup on this IP shows that the syrianelectronicarmy.com domain is also linked to this IP (reference – http://reverseip.domaintools.com/search/?q=141.105.64.37).

So can we work out owns or is helping syrianelectronicarmy.com? – repeat and rinse the above.

http://whois.domaintools.com/syrianelectronicarmy.com shows the registrant information linked to a privacy service based in the US (reference – http://whois.domaintools.com/syrianelectronicarmy.com):

REGISTRANT CONTACT INFO
Whois Privacy Protection Service, Inc.
Whois Agent
PMB 368, 14150 NE 20th St – F1
Bellevue
WA
98007
US
Phone:         +1.4252740657
Fax:           +1.4259744730
Email Address: 

Should be no bother for US law enforcement to get info out of a domestic entity.  Further to that, the registered address is a UPS store in Washington (reference – http://www.theupsstorelocal.com/1181/);  really Syrian terrorists? The contact email address shows another domain – protecteddomainservices.com – rinse and repeat again (reference – http://whois.domaintools.com/protecteddomainservices.com).

Domain Name:     protecteddomainservices.com
Registrar:       Christian Investments LLC

REGISTRANT CONTACT INFO
Protected Domain Services
Protected Domain Services
191 University Blvd.
Unit 384
Denver
CO
80206-4613
US
Phone:         +1.7206339075
Email Address: 

This time its a Colorado address.  Are US nationals doing their best to protect the identity of the owners of syrianelectronicarmy.com?

Am I missing something?

Also of note is that the contact details for Shorefront Media Inc shows a Russian name and Address:

Andrey Shevchenko
Navitel Rusconnect
19/2 Lva Tolstogo st.
Moscow 119034
Russia

Have a look at www.shorefrontmedia.com. Does this really look like a website for a media marketing company.  They can’t even market themselves.  A quick Google search links this Moscow address to quite a number of reports of phishing, spamming and hacking (http://www.google.com/search?q=19/2+Lva+Tolstogo+st.+Moscow+119034+Russia).

Is this the real home of the “Syrian Electronic Army”?  Is the “Syrian” part of the name being used to demonize Syria in the same way that Russians were in 80’s and 90’s spy movies?

Dot Net Nuke – A critical error has occurred. An unexpected error has occurred

Some of you might have seen this error after upgrading your DNN from v6 to v7.  It’s a bit scarey because it means that no-one can log into your DNN instance, not even a super user.  Troubleshooting must therefore begin on the hosting server.  Check out the log files under .\Portals\_default\Logs.  For me the critical error was:

2013-08-23 17:09:52,491 [hub][Thread:14][ERROR] DotNetNuke.Services.Exceptions.Exceptions – ~/Default.aspx?tabid=126&error=An unexpected error has occurred
System.ArgumentException: Parameter count does not match Parameter Value count.
at Microsoft.ApplicationBlocks.Data.SqlHelper.AssignParameterValues(SqlParameter[] commandParameters, Object[] parameterValues)
at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(String connectionString, String spName, Object[] parameterValues)
at DotNetNuke.Security.Membership.Data.SqlDataProvider.UpdateUser(Int32 userId, Int32 portalID, String firstName, String lastName, Boolean isSuperUser, String email, String displayName, Boolean updatePassword, Boolean isApproved, Boolean refreshRoles, String lastIpAddress, Boolean isDeleted, Int32 lastModifiedByUserID)
at DotNetNuke.Security.Membership.AspNetMembershipProvider.UpdateUser(UserInfo user)
at DotNetNuke.Entities.Users.UserController.UpdateUser(Int32 portalId, UserInfo user, Boolean loggedAction, Boolean clearCache)
at DotNetNuke.Entities.Users.UserController.UserLogin(Int32 portalId, UserInfo user, String portalName, String ip, Boolean createPersistentCookie)
at DotNetNuke.Modules.Admin.Authentication.Login.ValidateUser(UserInfo objUser, Boolean ignoreExpiring)
at DotNetNuke.Modules.Admin.Authentication.Login.UserAuthenticated(Object sender, UserAuthenticatedEventArgs e)
at DotNetNuke.Modules.Admin.Authentication.Login.OnLoginClick(Object sender, EventArgs e)
at System.Web.UI.WebControls.LinkButton.RaisePostBackEvent(String eventArgument)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

The error mentions a mismatch between passed parameters and those that are expected, ie:

at DotNetNuke.Security.Membership.Data.SqlDataProvider.UpdateUser(Int32 userId, Int32 portalID, String firstName, String lastName, Boolean isSuperUser, String email, String displayName, Boolean updatePassword, Boolean isApproved, Boolean refreshRoles, String lastIpAddress, Boolean isDeleted, Int32 lastModifiedByUserID)

So first place to look is at the Stored Procedure called UpdateUser and see what it’s expecting.  You can do this in SQL Server Management Studio, navigate to your DB, open programmability and expand Stored Procedures.  Down towards the bottom is a SP called dbo.UpdateUser.  Right click on it and select Modify and you can see the guts of what it does:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[UpdateUser]
@UserID         int,
@PortalID        int,
@FirstName        nvarchar(50),
@LastName        nvarchar(50),
@IsSuperUser    bit,
@Email          nvarchar(256),
@DisplayName    nvarchar(100),
@VanityUrl        nvarchar(100),
@UpdatePassword    bit,
@Authorised        bit,
@RefreshRoles    bit,
@LastIPAddress    nvarchar(50),
@passwordResetToken uniqueidentifier,
@passwordResetExpiration datetime,
@IsDeleted        bit,
@LastModifiedByUserID int
AS
UPDATE dbo.Users
SET
FirstName = @FirstName,
LastName = @LastName,
IsSuperUser = @IsSuperUser,
Email = @Email,
DisplayName = @DisplayName,
UpdatePassword = @UpdatePassword,
PasswordResetToken=@passwordResetToken,
PasswordResetExpiration=@passwordResetExpiration,
LastIPAddress = @LastIPAddress,
LastModifiedByUserID = @LastModifiedByUserID,
LastModifiedOnDate = getdate()
WHERE  UserId = @UserID

IF @PortalID IS NULL
BEGIN
UPDATE dbo.Users
SET
IsDeleted = @IsDeleted
WHERE  UserId = @UserID
END
ELSE
BEGIN
UPDATE dbo.UserPortals
SET
Authorised = @Authorised,
RefreshRoles = @RefreshRoles,
VanityUrl = @VanityUrl,
IsDeleted = @IsDeleted
WHERE  UserId = @UserID
AND PortalId = @PortalID
END

If you look closely you’ll see a few extra parameters included in addition to those shown in the original error message:

Stored Procedure	Query Error
@UserID         int,	Int32 userId
@PortalID int,	Int32 portalID
@FirstName nvarchar(50),	String firstName
@LastName nvarchar(50),	String lastName
@IsSuperUser    bit,	Boolean isSuperUser
@Email          nvarchar(256),	String email
@DisplayName    nvarchar(100),	String displayName
@VanityUrl nvarchar(100),
@UpdatePassword bit,	Boolean updatePassword
@Authorised bit,	Boolean isApproved
@RefreshRoles bit,	Boolean refreshRoles
@LastIPAddress nvarchar(50),	String lastIpAddress
@passwordResetToken uniqueidentifier,
@passwordResetExpiration datetime,
@IsDeleted bit,
@LastModifiedByUserID int	Int32 lastModifiedByUserID

To get things back up and running I removed all instances of these ‘extra’ parameters from the Stored Procedure and submitted the changes (Query -> Execute menu item).  My updated Stored Procedure was:

USE [DB NAME]
GO
/****** Object:  StoredProcedure [dbo].[UpdateUser]    Script Date: 08/23/2013 17:23:33 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[UpdateUser]
@UserID         int,
@PortalID        int,
@FirstName        nvarchar(50),
@LastName        nvarchar(50),
@IsSuperUser    bit,
@Email          nvarchar(256),
@DisplayName    nvarchar(100),
@UpdatePassword    bit,
@Authorised        bit,
@RefreshRoles    bit,
@LastIPAddress    nvarchar(50),
@IsDeleted        bit,
@LastModifiedByUserID int
AS
UPDATE dbo.Users
SET
FirstName = @FirstName,
LastName = @LastName,
IsSuperUser = @IsSuperUser,
Email = @Email,
DisplayName = @DisplayName,
UpdatePassword = @UpdatePassword,
LastIPAddress = @LastIPAddress,
LastModifiedByUserID = @LastModifiedByUserID,
LastModifiedOnDate = getdate()
WHERE  UserId = @UserID

IF @PortalID IS NULL
BEGIN
UPDATE dbo.Users
SET
IsDeleted = @IsDeleted
WHERE  UserId = @UserID
END
ELSE
BEGIN
UPDATE dbo.UserPortals
SET
Authorised = @Authorised,
RefreshRoles = @RefreshRoles,
IsDeleted = @IsDeleted
WHERE  UserId = @UserID
AND PortalId = @PortalID
END

After updating this you should be able to once again log in to your DNN portal.  Enjoy……

Speeding up login times – Group Policy v’s Branded IE

This is the age-old issue of balancing the need to get log in times as quick as possible v’s keeping the M in MOE.  The Environment can be managed to the ‘nth degree but each extra tweak comes at the expense of an extra micro second at login.

For me Management is key as I look after around 3500 student facing and lecture theatre PCs.  Due to SAN space issues we don’t provide roaming profiles, but do redirect Desktops and My Documents as well as a couple of system folders to user home drives.  Further complexity arrives in the form of different settings required depending on the user type logging in to the PC.  They can be a University Student, Teaching Staff, TAFE students or even the general public, and each needs a different home drive pointer, different proxy settings (configured for IE and Firefox), and in some cases unique wallpaper; and that’s just the start of it.

As a result, for a number a years I didn’t think too much about login times in the region of 90 – 120 seconds, but earlier this year it became a bit of a bug-bear for me and so the investigations began.  It was sparked by a persistent message saying Personalized Settings – Setting up personalized settings for: Browser Customizations which was hanging around a bit too long.

To kick things off I enabled verbose messaging; see http://support.microsoft.com/kb/316243 (I actual like this level of messaging, even for end users; at least you know Windows is doing something when it’s doing its thing).

Following that came the usual verbose Group Policy logging – http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx

Analysing these logs didn’t show up any obvious error so I went delving for other logs written at login (system wide) to see it they would shine any light.  I came across a few log files being written in the Local Application Data (%LOCALAPPDATA%\Local\Microsoft\Internet Explorer), brndlog.* and rsoplog.*.  Within these files I found some surprising data….

For each login there were two brndlog files generated, a brndlog.bak and a brndlog.bak.  The run of the files seemed pretty normal until the very end:

brndlog.bak:

08/20/2013 13:38:44    Refreshing browser settings…
08/20/2013 13:38:44    Broadcasting “Windows settings change” to all top level windows…
08/20/2013 13:39:24    Done.
08/20/2013 13:39:24 Done.
08/20/2013 13:39:24 Done.

brndlog.bak:

08/20/2013 13:39:27    Refreshing browser settings…
08/20/2013 13:39:27    Broadcasting “Windows settings change” to all top level windows…
08/20/2013 13:39:40    Done.
08/20/2013 13:39:40 Done.
08/20/2013 13:39:40 Done.

A quick bit of maths shows that there’s 53 seconds of ‘broadcasting’ going on for this particular login – even longer in other cases.  So, what does all this mean?

A quick big of research on brndlog led me here – http://blogs.msdn.com/b/askie/archive/2012/06/20/internet-explorer-maintenance-brndlog-txt-what-is-it-and-how-to-use-it-when-troubleshooting.aspx and here – http://support.microsoft.com/default.aspx?scid=kb;EN-US;941158 which were the only links I could find that dealt with delays relating to these logs.  None of the troubleshooting suggestions helped in this instance, but at least I now had a fair idea that IE (and its branding) was to blame.

What is branding anyway?

Branding of IE is done using an IEAK (MS Link) usually by System Administrators or Application Packagers to package up the browser with pre-configured settings for deployment in a corporate or other environment.  Branding is particularly useful in scenarios where Internet Explorer is deployed without the availability of a domain to deliver policy.  The ‘branding’ can include settings like proxy configuration, favorites and security settings etc.  The problem is though that in a managed environment using Group Policy for IE configuration, the branded settings seem to fight with the policy applied settings for the final say.

What to do when your SOE has a branded IE embedded in it?

My first thoughts were to strip out the branding.  I found a page on this topic – http://www.enhanceie.com/ie/NoBrand.htm. One of the suggestions was to remove the install.ins file that holds the branding information.  For me it was in %ProgramFiles(x86)% & %ProgramFiles%\Internet Explorer\SIGNUP\install.ins.  Removing this caused the desktop not to load at all.  Delving deeper I found that the branding file was for an older version of IE, Version=8,00,7601,17514.  So next I tried replacing it with an up to date version as our SOE now has IE9.  Again the desktop would not load.  Plan C was to break the branding, i.e. inject an install.ins that would cause it to fail, e.g.:

install.ins:

[Branding]
Wizard_Version=9.00.8112.16421
InstallIEVersion=9,0,8112,16421

I deploy this as a File Preference by Group Policy and amazingly it worked a treat.  The Personalized Settings dialog that so bugged me disappears as quick as it appears.  The brndlog files now appear as:

brndlog.bak

08/20/2013 15:21:08 ! Setup of the branding process failed with E_UNEXPECTED.

brndlog.txt

08/20/2013 15:21:10 ! Setup of the branding process failed with E_UNEXPECTED.

The IE browser settings deployed by Group Policy are applied as expected and the login process is down from over 90 seconds to around 25 seconds for a new profile including printer installation (no mandatory profiles used).  As expected, all this effort generated exactly zero calls to the Service Desk, and exactly zero users calling to say how great things are running (it’s just expected), but the satisfaction of further streamlining the MOE is satisfaction enough.

Resetting the rearm count in Windows 7

After installing Windows 7, and before activation, the operating system will run in an Initial Grace Period license status for 30 days. When this grace period expires, users can rearm Windows 7 for an additional 30 days, and do this up to 3 times, effectively allowing the OS to run legally for 120 days without a genuine product key.

When a user uses up all three rearms available rearms, the only option left is to enter a genuine product key to activate Windows 7, or leave the operating system in a crippled, non-genuine state.  Users will then be subjected to certain annoyances such as black desktop background, repetitive notification messages stating that this copy of Windows is illegal or counterfeited, and a reminder to register the software at login.

Through a Windows Product Activation (WPA) vulnerability that Microsoft introduced in Windows 7, it is possible to reset the remaining rearm count back to 4. There is no limit to the number of times that the rearm count can be reset, meaning that a user could theoretically run an unlicensed copy of Windows 7 forever, without the need for proper activation, and without applying any activation hacks.

This WPA vulnerability is related to a WPA registry key which contains the ‘Last Rearm Time’. When the WPA registry key is deleted, the whole licensing status of Windows 7 is re-initiated to the Initial Grace Period as if Windows 7 has just been installed. The deletion of the WPA registry key is achieved via the following command:

reg load HKLM\MY_SYSTEM “%~dp0Windows\System32\config\system”
reg delete HKLM\MY_SYSTEM\WPA /f
reg unload HKLM\MY_SYSTEM

Given the importance of this WPA registry key, Microsoft has locked it (and its sub-keys) from been modified or deleted in a normal user session. The only way to run this command is within the WinRE (Windows Recovery Environment) or WinPE (Windows Preinstallation Environment).

In our managed environment, this method of rearming Windows is ultra handy in our SOE creation, in that we do not have to keep starting from scratch when we run out of rearms.  This ‘hard’ rearm reset  gives us one less thing to worry about if we need to tweak anything in our images.

To perform this ‘hard’ reset; create a batch script file with the following commands:

1. reg load HKLM\MY_SYSTEM "%~dp0Windows\System32\config\system"
reg delete HKLM\MY_SYSTEM\WPA /f
reg unload HKLM\MY_SYSTEMSave the file as delwpa.bat on drive C:\ at the root folder level. For example, C:\delwpa.bat. Note that some users may require to run the text editor such as Notepad as administrator to save to C:\ root directory.
2. Restart the computer.
3. Press F8 right after the BIOS screen to get to the “Advanced Boot Options”.
4. Select Repair Your Computer.
5. Select your keyboard input method, and click Next.
6. Enter user name and password login credentials, and click OK.
7. In the “System Recovery Options”, open Command Prompt.
8. Type C: to go to the main drive, and the execute the delwpa.bat file by typing its name:delwpa.batNote: On some computers such as virtual machine or computer with recovery partition, the main drive may have another drive letter, e.g. D:
9. The console should display messages saying that the commands were executed successfully. Close the console window and reboot the machine.
10. After system start-up, log into Windows. Your system will display message such as “This product is not genuine”. Just ignore it.
11. To check the activation status, open an elevated command prompt window as administrator, and run the following command:slmgr /dlvThe dialog box with the following details should appear:

    License Status: Initial Grace Period
    Time remaining: 30 days
    Remaining windows rearm count: 3

Tip: As an alternative, it’s possible boot from a Windows 7 Repair Disc or a Windows 7 installation disc to go to WinPE environment.  This method will bypass the need to enter login credentials. Pressing F8 will bring user to WinRE console.

Powershell script to query Dell website for Warranty End Date

This little powershell script uses WMI to get the local PCs Service Tag from the bios.  It then queries Dell’s website for the warranty information and loops through each warranty line item to find the latest date.  Once we have the date, it is then written to the registry.  The warranty end date is then ready to be used in BGInfo or exported to a MOE tool such as Altiris NS for easy reporting.

[System.Reflection.Assembly]::LoadWithPartialName(“System.Windows.Forms”)

[String]$ServiceTag = $(Get-WmiObject -Class “Win32_Bios”).SerialNumber
$AssetService = New-WebServiceProxy -Uri “http://xserv.dell.com/services/AssetService.asmx?WSDL”;
$ApplicationName = “AssetService”;
$Guid = [Guid]::NewGuid();
$Asset = $AssetService.GetAssetInformation($Guid,$ApplicationName,$ServiceTag);
$Writer = New-Object “System.IO.StringWriter”;
$XmlSerializer = New-Object System.Xml.Serialization.XmlSerializer($Asset.GetType());
$XmlSerializer.Serialize($Writer,$Asset);
[String]$Result = $Writer.ToString();
$Writer.Flush();
$Writer.Close();

[xml]$dellinfo = $Result

foreach ($set in $dellinfo.ArrayOfAsset.Asset.Entitlements.EntitlementData)
{
    [DateTime]$date = Get-Date $set.EndDate
    if ($date -gt $maxdate)
    {
            $maxdate = $date
    }
}

#[System.Windows.Forms.MessageBox]::Show($maxdate.ToShortDateString(), “maximum”)

if (Test-Path ‘HKLM:\Software\DellWarranty’ -erroraction silentlycontinue) {
    #”Registry key HKLM:\Software\DellWarranty already exists.”
} else {
    md HKLM:\Software\DellWarranty
}

if (Get-ItemProperty -Name “WarrantyExpiry” -path ‘HKLM:\Software\DellWarranty’ -erroraction silentlycontinue) {
    #”Registry key HKLM:\Software\DellWarranty\WarrantyExpiry already exists.”
} else {
    New-ItemProperty “HKLM:\Software\DellWarranty” -Name “WarrantyExpiry” -Value $maxdate.toshortdatestring() -PropertyType “String”
}

Running 64bit from a 32bit environment

As we know, there’s a little feature in 64 bit windows that auto redirects 32 bit apps to 32 bit versions of system files via the WOW64 file system redirector. This causes some issues when deploying apps via things like older versions of Altiris NS to 64 bit Operating Systems.

This can be overridden via a little known feature called sysnative. Using this special alias will tell windows not to redirect to 32bit system files, ie we can run windows installers in 64 bit mode by launching it from a 64 bit cmd line launched from the 32 bit Altiris Agent environment:

%windir%/Sysnative

NOTE: If you try to use sysnative in a 64 bit cmd line it will fail as it is a virtual directory in the 32bit environment, not the real one.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx

How to test:

On 64 bit OS, run C:\Windows\SysWOW64\cmd.exe

run ‘set’ and check PROCESSOR_ARCHITECTURE = x86 (32bit)

cd %windir%\sysnative

run ‘cmd.exe’

run ‘set’ and check PROCESSOR_ARCHITECTURE = AMD64 (64bit from a 32bit command line!!)

Troubleshooting Tools in Windows 7

Microsoft provides a couple of useful tools within Windows 7 to assist with gathering thorough troubleshooting information.

One is called Problem Steps Recorder. To access this click on Start -> type ‘psr.exe’ -> hit Enter. You will then see a small and simple GUI appear for this very handy tool.

Once you (or a user) clicks on Start Record, it will record screen shots and input actions providing a step by step run-through of any scenario.

You (or the user) can add comments to the recording to provide additional information. This can be very handy, especially when escalating or assigning calls to other team members. It can also be very useful in scenarios where you can’t remote control a PC, where the user can record an issue any send you through the results.

Once you are finished you can click on Stop Recording and save the recording as a zip file. Compressed within the zip is an mht file which can be opened in Internet Explorer or Microsoft Word. An example recording is attached.

A second tool is the Reliability Monitor. This tool provides a calendarised view of various error types and is an easy way to view if there are repeated errors relating to certain applications. Again, this can greatly assist with PCs that are not behaving as it identifies which applications are causing problems and exactly when. It also provides a score of the overall stability of the system. This can be found by clicking start -> type ‘reliability’ -> hit enter or in ‘Control Panel\System and Security\Action Center\Problem Reports’

Hopefully you’ll find these useful.

Sophos Anti-Virus and Microsoft Recommended Exclusions

One of the recommendations from a recent MS WDRAP was to have a look at anti-virus configurations, in particular the exclusion settings. Microsoft publish a good overview of the various exclusions to configure depending on the services being run on a particular machine:

http://social.technet.microsoft.com/wiki/contents/articles/953.windows-anti-virus-exclusion-list-en-us.aspx

Of note for student labs for this is the recommendation for SQL boxes. The majority of our student machines run a default 2008 instance with many more running an additional 2008 R2 instance for a piece of software called NVivo. One of the listed documents is designed for PCs in Enterprise environments:

http://support.microsoft.com/kb/822158

There is one minor gotcha with Sophos exclusions though, see:

http://www.sophos.com/en-us/support/knowledgebase/13045.aspx

It appears that short file names also need to be configured for exclusions alongside the long file names, especially where legacy applications exist (whatever and wherever they are). If you have not configured this properly, the only real problem you will find will be performance issues due to the constant scanning by Sophos.

32 bit ODBC data sources on Windows 7 x64

We had an interesting call come through today with a user unable to configure a Microsoft Access System DSN in the ODBC Data Source Administrator on a Windows 7 x64 PC.

The crux of this issue is that as our Windows 7 SOE is 64bit, and by default the ODBC Data Source Administrator tool in the Control Panel only shows 64bit data source drivers. As our Office install in the 32bit version there aren’t any 64bit MS Office ODBC drivers installed. Running ‘Set up data sources (ODBC)’ from the control panel runs C:\windows\system32\odbcad32.exe. The 32 in the name of this executable is a bit misleading as it only displays 64 bit ODBC drivers.

To see the 32 bit ODBC drivers, and to set up new 32bit ODBC connections, you should instead manually run C:\windows\syswow64\odbcad32.exe

A bit of Light Reading

Microsoft has released a few free e-books that might be of interest:

http://blogs.msdn.com/b/microsoft_press/archive/2012/05/04/free-ebooks-great-content-from-microsoft-press-that-won-t-cost-you-a-penny.aspx

Introducing SQL Server 2012

Introducing SQL Server 2008 R2

Introducing Windows Server 2008 R2

Understanding Virtualisation Solutions

Office 365

First Look at Office 2010

Security and Privacy for MS Office 2010 Users

Deploying Windows 7

Moving to Visual Studio 2010

Programming Windows Phone 7