Digital Chalk Talk Videos – detailed technical overviews of the new Windows Azure services and supporting technologies as announced June 7, including Virtual Machines (IaaS Windows and Linux), Storage, Command Line Tools
http://www.meetwindowsazure.com/DigitalChalkTalks
Windows Azure Scenarios Videos on You Tube – “how to” guides, including “Create and Manage Virtual Networks”, “Create & Manage SQL Database”, and many more
http://www.youtube.com/user/windowsazure
“Watch Learn Live” event from TechEd Orlando, Monday June 11 – with priority for large Enterprise customers, webcasts on key announcements and topics for Windows Azure, including Virtual Machines (IaaS) and Networking. Recordings of these Sessions are available.
http://northamerica.msteched.com/#fbid=aGO7e9TvNQU
90 Day Free Trial - we would like to confirm that the Preview Period in support of the new release of Windows Azure is now available, which will enable you to evaluate the new Virtual Machines/IaaS and Enterprise Networking capabilities. Once you have registered for the 90 Day Free Trial and created a new Account, you can access the Preview directly at this link:
https://account.windowsazure.com/PreviewFeatures
OK, so anyone who knows me very well knows I'm a big fan of Paint Shop Pro. I'm not a huge Photoshop fan, although I like Fireworks, and some other graphics programs. See, I started out on Aldus Photostyler, and was a big IrfanView user, when Jasc originally came to market with PSP. Anyhow, I'm running the Windows 8 CP on a new AMD A6-3500 APU with Radeon Graphics, with 4GB of RAM. Obviously it's 64bit, but it has more than enough power to run PSP X4. When I installed PSP X4 however, either with the "Try before you buy" version, or the retail purchased download I have, it fails to start after install. Checking the event logs pointed to the culprit in the Application event logs:
Faulting application name: Corel PaintShop Pro.exe, version: 14.0.0.114, time stamp: 0x4e0f4a24Faulting module name: mfc90u.dll, version: 9.0.30729.4148, time stamp: 0x4a596d4aException code: 0xc0000005Fault offset: 0x000a11afFaulting process id: 0x1bcFaulting application start time: 0x01cd30039bea85cdFaulting application path: C:\Program Files (x86)\Corel\Corel PaintShop Pro X4\Corel PaintShop Pro.exeFaulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4148_none_4bf5400abf9d60b7\mfc90u.dll
Hmmm... great. A Visual C++ redistributable error. Some preliminary rectification efforts failed for me, as did finding much information online. I did however stumble upon another forum that led me to the right solution: Download the Service Pack 1 for PSP X4.
That did the trick, and now I can resume my alter-ego career in web design. :)
One common customer request that comes in is that they would like to collect the Security Event Logs from their Windows Azure roles, in addition to their Application, System and other Event Logs, when collecting diagnostics information using the Windows Azure Diagnostics capabilities. Security event logs are notoriously tricky, because to write them you require administrative privileges, which means you normally have to run as an elevated user account. But the ability to collect these in one place (a Windows Azure Storage Account) across a variety of role instances running in the cloud, can be a major plus for a Security Administrator, and coupled with System Center Operations Manager support for Windows Azure, is quite cool.
So let’s start by taking for example just dumping your Security events to a log file on your Windows machine. In Windows 7 on upwards, you can use the wevtutil tool to do so: WEVTUTIL epl Security SecurityEventLog.evtx Note that this will dump the entire log, but you could just dump a few events in XML format, say like the last three: wevtutil qe Security /c:3 /rd:true /f:xml > SecurityEvents.xml You can only runs these on your machine from an elevated command prompt, or you will get an “Access is denied.” error. This is by design, for increased security: Only an administrative user should be able to interrogate the machine’s Security events. It’s really no different on a Windows Azure VM that runs as one of your Web, Worker or VM role instances. Thus, configuring diagnostics to collect the systems Security event logs, requires the diagnostics classes to access within the context of a process running as an Administrative user. However, by default Windows Azure runs code and processes as a standard user. You generally will feel like you have two choices:
a) Add a new Administrative user, and run your code or diagnostics there, which means creating a new user account, and giving that account Administrative rights. To do that programmatically once the VM is started, it means adding a new administrative user, and then impersonating that user with managed code just to run some command line tools to collect the Security Events. Then you have the issue of moving those events off the machine to Windows Azure Storage, in the format expected, etc. This is a lot of “heavy lifting” and will end up being unnecessary, as you will shortly see. You can define a startup task, with it’s executionContext attribute set to run elevated. or b) Add permissions so that the Security Events could be read by standard users: NET.EXE localgroup "Event log Readers" "Everyone" /ADD This approach not only would require you to reboot the Windows Azure VM (losing machine state), but would defeat the security principle of not allowing unprivileged users access to the Security event logs. Therefore, I would recommend this approach in the least.
a) Add a new Administrative user, and run your code or diagnostics there, which means creating a new user account, and giving that account Administrative rights.
or
b) Add permissions so that the Security Events could be read by standard users: NET.EXE localgroup "Event log Readers" "Everyone" /ADD This approach not only would require you to reboot the Windows Azure VM (losing machine state), but would defeat the security principle of not allowing unprivileged users access to the Security event logs. Therefore, I would recommend this approach in the least.
But there is a better way. The Diagnostics Plug-In Module configuration. The diagnostics plug-in, which is configured by importing the module, and configuring the default configuration for you, actually runs the diagnostics processes as startup tasks, with an increased priority level. This configuration is pulled into the Windows Azure Project when it is built, from the Windows Azure SDK folders, which reside on your machine when you install the SDK. What this meant for me was I could navigate to the plug-in SDK folder, and change the configuration of the plug-in:
a) I navigated to C:\Program Files\Windows Azure SDK\v1.6\bin\plugins\diagnostics and opened the Diagnostics.csplugin folder in Notepad. b) Changed the startup task Diagnostics uses to run elevated. The file now looked like so: <?xml version="1.0" ?><RoleModule xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" namespace="Microsoft.WindowsAzure.Plugins.Diagnostics"> <Startup priority="-2"> <Task commandLine="DiagnosticsAgent.exe" executionContext="elevated" taskType="background" /> <Task commandLine="DiagnosticsAgent.exe /blockStartup" executionContext="elevated" taskType="simple" /> </Startup> <ConfigurationSettings> <Setting name="ConnectionString" /> </ConfigurationSettings></RoleModule>
<?xml version="1.0" ?><RoleModule xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" namespace="Microsoft.WindowsAzure.Plugins.Diagnostics"> <Startup priority="-2"> <Task commandLine="DiagnosticsAgent.exe" executionContext="elevated" taskType="background" /> <Task commandLine="DiagnosticsAgent.exe /blockStartup" executionContext="elevated" taskType="simple" /> </Startup> <ConfigurationSettings> <Setting name="ConnectionString" /> </ConfigurationSettings></RoleModule>
Now any project I now build, package and deploy to Windows Azure from my machine using Visual Studio’s Windows Azure Tools will configure the plugin to run with the DiagnosticsAgent running in an Administrative context.
I now went ahead and added a diagnostics.wadcfg to my root WorkerRole project, and made sure it’s Build Action was set to Content, and Copy to Output Directory was set to “Always”. This ensures the file will end up in the E:\approot directory on my Windows Azure VM, where the Diagnostics Plug-In will use it to configure Diagnostics with my declerative request to copy the Security Event Logs. Since it is running Administrative, it picks up the events as you would expect.
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration" configurationChangePollInterval="PT1M" overallQuotaInMB="10240"> <DiagnosticInfrastructureLogs bufferQuotaInMB="512" scheduledTransferLogLevelFilter="Verbose" scheduledTransferPeriod="PT1M" /> <Logs bufferQuotaInMB="1024" scheduledTransferLogLevelFilter="Verbose" scheduledTransferPeriod="PT5S" /> <Directories bufferQuotaInMB="1024" scheduledTransferPeriod="PT1M"> <!-- These three elements specify the special directories that are set up for the log types --> <CrashDumps container="wad-crash-dumps" directoryQuotaInMB="512" /> <FailedRequestLogs container="wad-frq" directoryQuotaInMB="512" /> <IISLogs container="wad-iis" directoryQuotaInMB="512" /> </Directories> <PerformanceCounters bufferQuotaInMB="512" scheduledTransferPeriod="PT1M"> <!-- The counter specifier is in the same format as the imperative diagnostics configuration API --> <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT1M" /> <PerformanceCounterConfiguration counterSpecifier="\Memory\Available Mbytes" sampleRate="PT5S" /> <PerformanceCounterConfiguration counterSpecifier="\ASP.NET Apps v4.0.30319(__Total__)\Requests/Sec" sampleRate="PT1M" /> </PerformanceCounters> <WindowsEventLog bufferQuotaInMB="512" scheduledTransferLogLevelFilter="Verbose" scheduledTransferPeriod="PT1M"> <DataSource name="System!*" /> <DataSource name="Application!*" /> <DataSource name="Security!*" /> </WindowsEventLog> </DiagnosticMonitorConfiguration>
Hope this approach will save some of you some time and effort.
-Eric
Join us LIVE from the Microsoft Redmond Campus next Tuesday, December 13, 2011 for “Learn Windows Azure”, a FREE event for developers to learn how to get started building applications for the cloud with Windows Azure. At this event you will learn how to get started building applications for the cloud from Scott Guthrie, Dave Campbell, and Mark Russinovich and several others. The entire event will broadcast live from Microsoft’s Redmond Campus so you can watch online from anywhere in the world.
Learn Windows Azure will start at 9 a.m. and will conclude at 5 p.m. Pacific Standard Time. A limited number of seats are also available to attend the event in-person at the Microsoft Redmond Campus. Registration is required to reserve your seat for the in-person event. Register now to reserve your seat for the in-person event or receive a reminder for the online event.
We will cover the following topics during the event:
9:00 – 10:30 a.m. – Getting Started with Windows Azure: Learn how to get started building applications for Windows Azure with the Windows Azure SDK & Tools from Microsoft Corporate VP Scott Guthrie.
10:45 – 12 p.m. – Cloud Data & Storage: Join Microsoft Technical Fellow Dave Campbell and learn how to use SQL Azure and Windows Azure storage services in your cloud applications.
12:15 – 1:15 p.m. – Channel9 Cloud Cover Show Live: Join Steve Marx and Wade Wegner for this special live edition of the Cloud Cover Live Show to see some fresh Windows Azure demos and hear answers to common Windows Azure questions.
1:30 – 2:30 p.m. – Developing Windows Azure Applications with Visual Studio: In this session, Jay Schmelzer will show you how to use Visual Studio to its full potential to develop, debug, and deploy cloud applications.
2:45 – 3:45 p.m. – Building Scalable Cloud Applications: Do you want to build applications that are highly scalable, loosely coupled, and highly available? Then tune in for this session to learn about key Windows Azure services and patterns from David Aiken.
4:00 – 5:00 p.m. – Expert Panel Q&A featuring Scott Guthrie, Dave Campbell, and Mark Russinovich:
For additional information, read Scott Guthrie's blog post.
Submit your questions over Twitter with the #WindowsAzure hashtag and our engineering leaders will answer them live during the event.
Register Now!
Quick tip: When setting up your Windows Azure Hosted Services, if your planning on using VMRole instances, with a base image tied to an Affinity Group, make sure your Hosted Service belongs to that specific Affinity Group. I found out the hard way, sometimes some obvious deployments aren’t so obvious. Let me explain:
I have a Affinity Group I named “Chicago”, which is specified to use only the “North Central US” Windows Azure datacenter(s). I then uploaded a base image for my VM Role, anchored to that Affinity Group using csupload.exe (You can use the Add-VMImage cmdlet’s –AffinityGroup switch for that.)
I then created a Hosted Service, specifying “North Central US” as the location, rather than selecting the “Chicago” Affinity Group. I figured, the same data center location, as the affinity groups datacenter location, would logically be the place here. Makes sense, right?
So, off to VS to deploy my services, and blam:
12:28:50 AM - Preparing... 12:28:50 AM - Connecting... 12:28:52 AM - Uploading... 12:29:35 AM - Creating... 12:29:53 AM - HTTP Status Code: 400/nError Message: One of the specified images cannot be used for creating the deployment. When you want to create a deployment that is based on a machine image, one of the following constraints must be met: (1) the hosted service and the image belong to the same affinity group, or (2) neither the hosted service nor the image belong to an affinity group, but their location constraints are the same, or (3) the hosted service belongs to an affinity group and the image has a location constraint equal to the location constraint of the affinity group. Here are the details about the current deployment:Image ericgolbase.vhd belongs to an affinity group named ff338672-edb1-42ac-b996-c76d9caae20e, which is in location constraint North Central US.Hosted service office365 is not in an affinity group. Its location constraint is North Central US. /nOperation Id: afa4e7ee-af01-43eb-aa0e-202c64c7882b 12:29:53 AM - Deleting O365 12:29:54 AM - There was no endpoint listening at https://management.core.windows.net/f26e43b8-7496-44c6-8611-45441ef15854/services/hostedservices/office365/deploymentslots/Production that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. 12:29:54 AM - Deployment failed
Yeah, ok. ::Rolling Eyes:: So, I was a bit frustrated I would have to tear down, and recreate my service. Especially since I just got done uploading the service certificates I needed, and I didn’t want to have to wait to get any length of time to get my hosted services DNS name back on a re-create. Lucky for me, the process went smooth and I could continue to chow my salad while I waited a couple minutes, and re-start the deployment.
BTW, It also took me hours upon hours just to get my base image created this time around. Beware, this can be frustrating. In my case, I usually dual boot from my laptop, either to Windows 7 Enterprise, or to Windows Server 2008 R2. I use Windows Server 2008 R2 for Hyper-V, and have my laptop setup to use a VHD for that OS, since I also use Bitlocker Encryption all around. (Bitlocker rocks BTW.. turning the laptop into a nice paperweight weighing a few kilos for anyone thinking of stealing a laptop, unless they invest in a hard drive and have the knowledge how to change the thing out. Major deterrent.)
My issue first was I couldn’t expand the VHD to boot into my OS, because I had run out of disk space (I have dual 120GB SSD drives too…). After to cleanup with WinDirStat, and a portable USB (also bitlocker’ed.. ::evil chuckle:: ) I was back in business. [20 minutes spent.]
Then, a bunch of OS updates and reboots. Great, now I could get to image creation. [15 minutes spent.] I used my MSDN account, and dl’ed the latest Windows Server 2008 R2 media, which took about 15 minutes on my Cable Modem. [We’re up to 50 minutes.]
Now I could get down to business:
1) Create the VHD – check. 2) Patch the VHD – check (with multiple reboots). 3) Install the Integration Components (Guest Agent) for Windows Azure – check. 4) Install my apps – check. 5) Sysprep the VM – check.
1) Create the VHD – check.
2) Patch the VHD – check (with multiple reboots).
3) Install the Integration Components (Guest Agent) for Windows Azure – check.
4) Install my apps – check.
5) Sysprep the VM – check.
Finally ready to upload. [I’m at 90 minutes, yes, 40 minutes longer due to all the patching, even with the latest SP2 image from MSDN.] Then, the upload.. 10.6GB, and, I had to –SkipVerify for some weird reason. [Add 3 hours, 46 minutes.] Yes, over 5 hours to create a VMRole Image, and get it where it needs to be.
My hope is that over the course of the next year, some of the work our teams are doing will get this down to minutes, if not seconds, for our customers.