Over the past few months we have seen a number of situations where we encounter customers that have had horrendous issues with their websites.  As we work to resolve issues for these customers we often find that key information that either allows us to help them, or that would have prevented then from being in the situation that they were placed in.  After seeing a number of common trends we thought it would be important to start sharing some insight on some key items that should be known by all website owners, regardless of their technical ability.

We have been busy here at IowaComputerGurus for a while as we have been heads-down working on a massive set of updates to the documents, modules, tools, and resources that we make available on this site.  In addition to a major update for our brand and visual appeal.  It is with great honor that I reveal to you the fruits of our labor from the past months!

Over the past 24 hours we have assisted a large number of customers with server disasters, mostly stemming from a series of Windows Updates that went horribly wrong.  I blogged about the main issue on my personal blog today under the title, Windows Updates, Monitoring, and ASP.NET Oops!.  If you have not yet read this article, I strongly recommend you check it out as well as continuing with this article.  By most accounts that type of an issue would be considered a disaster with sites being down and resources unavailable to perform their regular duties.  Today's excitement prompted a lot of questions regarding the concept of true disaster preparedness and what levels of protection a customer needs to ensure their assets are properly protected. 

In this posting I will review the concept of Disaster Recovery Planning as we see it here at IowaComputerGurus.  Our goal here is to educate, to ensure that in the unfortunate case of a disaster that minimal data, if any, is lost.

It is a regular occurrence for us to receive requests from people that are experiencing extreme issues.  It could be a single site that is down, a whole server that is having problems or any combination of other issues.  While we totally understand the urgency behind each of these requests, it is amazing the types of security risks that users will put themselves into, just to get help.  In this post I will outline our "best practices" recommendation for balancing the line between security and the urgency for help.

If you have been paying attention to the news in recent months you have most likely heard of a few cases where user information, such as Usernames and Passwords, have been exposed from some high visibility websites. Some of the more current leaks were with Gawker and Mozilla. For those that are unfamiliar the situation is pretty simple. These sites store user login information, usernames and passwords, that allow users access to their systems. Their systems were then breached and malicious users were able to get access to the information. Why is this something that I am blogging about in relation to DotNetNuke? Well without a bit of configuration your site could be at risk, should a malicious user get access to your system. This article will discuss a bit around how/why there is a risk and how that relates to DotNetNuke, then it will progress into an overview of the default configuration of DotNetNuke and the recommended changes to the system.