Articles under DotNetNuke Best Practices
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.
A while back I blogged here about the process of Securing User Passwords in DotNetNuke and talked about the importance of setting up sites to use Hashed passwords rather than Encrypted. The other day I asked on Twitter if there was interest in a utility module that would handle the conversion process for users. Response was almost immediate and unanimous that it was a good item. Therefore without further delay I am proud to announce that we have done just that.
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.
Almost a year ago we published to this blog our first whitepaper, "DotNetNuke Performance Best Practices", in that time the document has been downloaded over five thousand times and we have received numerous e-mails with feedback regarding the contents of the document, the basis of our recommendations and suggestions on how to expand the document.
...
A majority of the time when working with a business there is a strong focus on keeping things working, and leaving working items as they are. However, when it comes to ensuring that business can continue as usual it is important to make sure that not only you have processes in place for backups, but backups alone are not going to do everything for you. It is important to test/validate the backups and also to ensure that you are taking backups at all times that are necessary. Below we will discuss our stance on these two topics.
In the past few weeks on my personal blog I have published articles on "Selecting a DotNetNuke Hosting Provider" as well as "Shared, Virtual Private Server, Dedicated or Cloud Hosting". Between these two articles the topic of hosting selection has been pretty well discussed, however, based on questions/comments that have been provided to us s...
Over the past few months IowaComputerGurus has fielded more and more questions surrounding the "how" part of DotNetNuke module/extension development. Along with these questions have been requests for "best practices" and other general information that if followed will help developers create solutions that work well within the DotNetNuke platf...
One of the most common questions that I have been asked over the past 1-2 years is; "How do you make DotNetNuke perform well?". Over the past few months I have given a few presentations on basic configuration elements and how you can tune DotNetNuke for the best performance possible. I will also be giving a presentation on the topic at ...
Well, somehow “a week or two” turned into 10 months since I posted part 1 of this case study. Since then, DotNetNuke 5.1 brought a minor improvement to DNN’s XML sitemap implementation and has grown more web standards compliant, but other than that the points discussed so far in regards to SEO still apply. With that in mind, let’s refer back to my ...
Recently on Twitter we noticed a discussion regarding another DotNetNuke vendor and how their website was not based on the DotNetNuke platform. The discussions that followed came to a very clear conclusion, the act of dogfooding the technology you work with is very important. For example, a company that "specializes" in DotNetNuke solutions and uses Joomla to manage their corporate website portrays a conflicted image, either intentionally or not. We have noticed this since the beginning of our company and have taken a unique approach to the management of our website and I thought it would be nice to share a bit on how we see our website impacting our potential customers.