Currently in Windows Azure Web sites, there is an option to store your website logs to Azure Blob Storage, but however, the FREB logs – failed request tracing logs, can only be stored in the file system. You will then grab them via your favorite FTP tool, and do the analysis. One of my co-worker asked this question on if we can store the Failed Request Tracing logs in the blog storage, and Richard Marr gave this interesting idea of using WebJobs to move the files to Azure Blob Storage. I tried this quickly, and have a beta version of a similar webjob ready for you if you want to try it.
Read the complete post here.
Yes, you are reading it right. It is true. It’s just a matter of one click to promote your staging website to be the production site. Gone are those hassles you were facing with publishing a new deployment to the live website, and some unbaked pages/assemblies, needless to say much pain, downtime, and probability of errors.
Read the complete post here.
Have you been looking a download of the IIS Administation cmdlets for Powershell for Windows 7 or Windows Server 2012 R2?
For earlier versions of Windows the IIS PowerShell Snap-in was a download, but with Windows 7 and Windows Server 2012 R2 the IIS PowerShell Snap-in is built into the operating system.
To enable the IIS PowerShell Cmdlets on Windows 7, please follow these steps.
1. From the Start menu, type in Windows Features, and select Turn Windows features on or off.
2. In the Windows Features control panel, expand Internet Information Services, expand Web Management Tools, and place checks next to IIS Management Scripts and IIS Management Service. Click OK to install.
3. When you are need to use the IIS PowerShell Cmdlets please follow these steps.
Open an Administrative PowerShell, and run the following commands.
Set-ExecutionPolicy unrestricted –force
The output should resemble the PowerShell window below.
You are now ready to use the IIS PowerShell Cmdlets on Windows 7.
Note: On an IIS 7.5 Server you may only need to complete step number 3.
However, if you need to install the IIS Management Scripts and IIS Management Service on Windows Server 2012, the “Windows Features” step will take you into the Server Manager.
Once in the Server Manager, you should start by selecting Roles. Once there you need to determine if IIS is already installed.
In the Roles Summary section, if you see Web Server (IIS) then IIS is installed.
If IIS is already installed scroll down to find the Web Server (IIS) section and click Add Role Service.
From here you will need to install the IIS Management Scripts and IIS Management Service.
If IIS is not installed click Add Role, select Web Server (IIS), and while selecting the role services insure that you select IIS Management Scripts and IIS Management Service.
I had an interesting question earlier today which I thought was worth sharing. One of my coworkers was trying to use the code sample from my Programmatically Flushing FTP Logs blog, and he was getting the following error:
Unhandled Exception: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
at Sample.Main() in c:\Projects\FtpTests\Program.cs:line 25
I knew that the code sample in my blog worked perfectly when I originally wrote it, so I figured that my coworker must be doing something wrong. (And every developer has said "It works on my computer..." at one time or other.) But I decided to give him the benefit of the doubt, so I copied the source code from my blog into a new Visual Studio project and I ran it.
Much to my surprise, I saw the same error that my coworker was seeing if I didn't step the code through with a debugger.
When I stepped through the code in a debugger, I saw the following error message:
At this point I was thinking, "What the heck? I know this code was working before..." I started to wonder if we had released a breaking change to the FTP service sometime during the past two years, but then it suddenly dawned on me: I hadn't started the FTP service on my computer.
That was the source of the problem: I usually have the FTP service configured for manual startup on my development computers, but the FTP methods to start and stop FTP sites and flush the FTP logs do not work when the FTP service is not running. Once both of us started the FTP service on each of our systems the problem went away.
I hope this helps. ;-](Cross-posted from http://blogs.msdn.com/robert_mcmurray/)
Whenever I am delivering a presentation where I need to use PHP, I typically use a batch file that I wrote in order to rapidly deploy PHP on the system that I am using for my demos. The batch file usually takes less than a second to run, which always seems to amaze people in the audience. As a result, I usually have several people ask me for my batch file after each presentation, so I thought that it would make a good subject for today's blog.
I should mention that I have used this batch file in order to demonstrate PHP with IIS in a variety of scenarios, and one of my favorite demos is when I would borrow someone's laptop and plug in a flash drive where I had IIS Express pre-installed, and then I would run the batch file in this blog to deploy PHP. Next I would launch IIS Express, open a web browser on their system, and then browse to http://localhost/ in order to show that IIS Express was working correctly. Lastly I would write a simple PHP "Hello World" page to show that PHP was up-and-running on their system in a matter of seconds.
That being said, I have to point out that there is a very important prerequisite that you must have in order to follow the steps in the blog: you need to start with a known-good installation of PHP from one of your systems, and I'll explain what I mean by that.
My batch file expects to find a folder containing ready-to-run files for PHP in order to deploy PHP on a new system. I originally obtained my PHP files by using the Web Platform Installer (WebPI) to install PHP, and then I copied the files to my flash drive or some other repository. (Note that WebPI usually installs PHP in the "%ProgramFiles(x86)%\PHP" folder.) If you don't want to use WebPI, you can also download PHP from http://windows.php.net/, but you're on your own for configuration.
Once I have the files from a known-good installation of PHP, I create the following folder structure in the location where I will be storing the files that I use to deploy PHP on other systems:
One thing to note is that the PHP.INI file you use may contain paths which refer to specific directories on the system from which you are copying your PHP files, so you need to make sure that those paths will exist on the system where you deploy PHP.
Here is an example: when I used WebPI to install PHP 5.5 on a system with IIS, it installed PHP into my "%ProgramFiles(x86)%\PHP\v5.5" folder. During the installation process, WebPI updated the PHP file to reflect any paths that need to be defined. At the time that I put together my notes for this blog, those updates mainly applied to the path where PHP expects to find it's extensions:extension_dir="C:\Program Files (x86)\PHP\v5.5\ext\"
What this means is - if you want to deploy PHP to some other path on subsequent systems, you will need to update at least that line in the PHP.INI file that you are using to deploy PHP. In my particular case, I prefer to deploy PHP to the "%SystemDrive%\PHP" path, but it can be anywhere as long as you update everything accordingly.
The following batch file will deploy the PHP files in the "%SystemDrive%\PHP" folder on your system, and then it will update IIS with the necessary settings for this PHP deployment to work:@echo off REM Change to the installation folder pushd "%~dp0" REM Cheap test to see if IIS is installed if exist "%SystemRoot%\System32\inetsrv" ( REM Check for the PHP installation files in a subfolder if exist "%~dp0PHP" ( REM Check for an existing installation of PHP if not exist "%SystemDrive%\PHP" ( REM Create the folder for PHP md "%SystemDrive%\PHP" REM Deploy the PHP files xcopy /erhky "%~dp0PHP\*" "%SystemDrive%\PHP" ) pushd "%SystemRoot%\System32\inetsrv" REM Configure the IIS settings for PHP appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='%SystemDrive%\PHP\php-cgi.exe',monitorChangesTo='php.ini',activityTimeout='600',requestTimeout='600',instanceMaxRequests='10000']" /commit:apphost appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='%SystemDrive%\PHP\php-cgi.exe',monitorChangesTo='php.ini',activityTimeout='600',requestTimeout='600',instanceMaxRequests='10000'].environmentVariables.[name='PHP_FCGI_MAX_REQUESTS',value='10000']" /commit:apphost appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='%SystemDrive%\PHP\php-cgi.exe',monitorChangesTo='php.ini',activityTimeout='600',requestTimeout='600',instanceMaxRequests='10000'].environmentVariables.[name='PHPRC',value='%SystemDrive%\PHP']" /commit:apphost appcmd.exe set config -section:system.webServer/handlers /+"[name='PHP_via_FastCGI',path='*.php',verb='GET,HEAD,POST',modules='FastCgiModule',scriptProcessor='%SystemDrive%\PHP\php-cgi.exe',resourceType='Either']" /commit:apphost popd ) ) popd
Once you have all of that in place, it usually takes less than a second to deploy PHP, which is why so many people seem interested during my presentations.
Note that you can deploy PHP for IIS Express just as easily by updating the "%SystemRoot%\System32\inetsrv" paths in the batch file to "%ProgramFiles%\IIS Express" or "%ProgramFiles(x86)%\IIS Express" paths. You can also use this batch file as part of a deployment process for PHP within a web farm; in which case, you will need to pay attention to the paths inside your PHP.INI file which I mentioned earlier.(Cross-posted from http://blogs.msdn.com/robert_mcmurray/)
Have you ever noticed that some existing content is not serving from your Azure Web Site and returns the following message
“The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.”
One reason this may occur is due to missing MimeTypes.
To see if this is the case Enable Detailed Error Messages in Site Diagnostics
After reproducing the issue gather the LogFiles/DetailedErrors folder for your site .
For A Mime Type issue you will see that his is 404.3 error
In the above error I purposely omitted the “Things you can try” section as this applies to on premise IIS and in Web Sites you cannot run APPCmd.exe to add settings
Instead you can simply add this to the web config . Here is any example for .woff extensions which I see quite often in Azure Web Site deployments
Add the following to the <system.webServer> section of your web.Config.
<mimeMap fileExtension=".woff" mimeType="application/x-font-woff" />
Note : If the <staticContent> element already exists you just need to add the <mimeMap> element to this section for the type you want to add
Websites being slow is perhaps the most common problem every website administrator, and developers run into. If they are extremely unlucky, then see this problem only in their production environment. Many troubleshooting techniques, best practices are available for this scenario. I will try to cover them in a different post as a part of my ASP.NET Troubleshooting series some other time. Meanwhile, you can try looking at this post of mine, where I’ve something that might help you.
For now, let’s focus on Windows Azure Web Sites. As you know this is a closed (well, not completely) hosting environment, and still there are a few things that you can do for this problem – for example, you can try collecting FREB traces for a long running request, and see where it is stuck.
Read the complete post here.