Showing posts with label DotNetNuke. Show all posts
Showing posts with label DotNetNuke. Show all posts

Sunday, 18 April 2010

Volcanic Fallout: How Did Your Company Shape Up?


Ongoing air travel and transport chaos in Europe caused by the size of the ash cloud from Iceland's Eyjafjallajoekull volcano has brought the fragility of our express/last-minute/on-demand civilisation into sharp focus and demonstrated just how at-risk our way of life is from natural disaster or catastrophe. It used to be called Act of God. Despite the minimal risk to human life on the mainland of Europe, this event still qualifies as a disaster because of the disruption and the knock-on effects worldwide.

This is not the place to try and sort out the huge problems piling up for Kenyan farmers for example, but we can look at the day-to-day running of our companies - the flow of information within the company and that flow's relationship with the movement and physical interaction of personnel within the company and with customers and clients.

In other words, we should be asking ourselves, "How did we, or how are we shaping up?" in the face of these problems.

This is not a new idea of course. Since the beginning of the Digital Age people have been looking at ways to wire up their businesses better and find ways to make the journeys of company personnel less and less necessary. Every disaster, whether it be local or global, has (or should have) inspired companies affected to re-examine their modus operandi. Unfortunately however, human nature being what it is, good intentions are liable to be forgotten in prolonged times of comfort and relatively easy mass travel. We get sloppy.

The European Volcanic Ash Cloud Disaster has had a very specific victim: jet air transport. Hopefully nobody is dying. Nobody is being made homeless. Or starving. And all telecoms are working normally. But it is beyond our control.

However, one of the things a company can actually control is the movement of its employees and consider whether disrupted journeys were really necessary in the first place. Clearly many journeys are necessary - I don't want to suggest anyone goes the way attempted by George Clooney's character's company in the rather disturbing film Up In The Air. For those unfamiliar with the plot, George Clooney plays a professional 'executioner' working for a company which is employed by other companies to come in and physically make all the redundancies. The result is that George Clooney spends most of his life in the air between appointments to downsize businesses. One of the central themes of the movie is his employer's attempts to do the whole thing by video link from head office, so doing away with George Clooney's travel and the personal and physical face-to-face meeting with the about-to-be-jobless. The scheme is a disaster, and the value of the genuine face-to-face meeting in such trying circumstances is proved.

So any George Clooney characters caught up in the Volcanic Ash Disaster will just have to get on with it the best they can and go to ground until it all blows over. Similarly the likes of the trade exhibition planned months before will just have to be cancelled. And on the customer side I am assuming that you have placed warnings about despatch and delivery times on e-commerce operations you may run.

But what businesses can do is check and overhaul their existing internal online systems and work out which areas could or should be done better.

Some questions:

Does your company have an Intranet?

If so, does it really work properly, and do your employees really use it to its potential? Or is it only used by a few geeky types at head office?

Are you cloud-computing? (Perhaps an unfortunate term under the circumstances). Are your employees able to work effectively from home, a hotel room or the hotspot in an airport?

Do you use Skype for Business?

Do you use Yammer?

Some other internal instant messaging service?

Was your cancelled international business meeting in Frankfurt on 19 April re-arranged with online white boards, screen and file sharing and video? If not, why not?

Do you do most of your in-house training online? (See our image at right).

Now clearly some of these questions cover similar ground and some won't be relevant to particular businesses. But can you put your hand on your heart and say that your company does the best possible job with the tools available online to minimise disruption inside your business in the face of a disaster preventing travel?

Well?


Go to this post's page at www.zinepal.com and get the PDF file or perform various sharing actions.

Friday, 20 November 2009

Glanton Hits Vegas - DotNetNuke Openforce 2009




John, Amisha and I sat back after the last session at Openforce 09 and, over a well-deserved Margarita at Cleopatra’s in Caesars Palace, we reflected on what had made the Openforce conference a success for us and why we’d recommend it to others.



Firstly, it was an appreciation of the DNN community. This is not your usual, large scale gathering of folks with a passing interest in technology on a company funded junket – this was more like a City Hall gathering in a small town – everyone was there because they wanted to be there, because they had something to contribute, something to share and because they wanted to see their community and its infrastructure grow stronger.



With our livelihoods so dependent on DotNetNuke Corp and how it manages its people, its strategy and the product, it was very re-assuring to meet all the main people, to experience first-hand how approachable they are and to feel that their door is always open. Navin Nagiah, the CEO, gave us a shout out in his session on DotNetNuke Commerce and Community as new Fusion partners.



Our mindsets have changed about our role in the ecosystem. No longer do we have to work so hard to sell DotNetNuke on its merits and its backing – Doug Howell (Director of Alliances) and Tom Kress (VP Sales) are there to support those activities and we’ll expect to see more sales and marketing support from these great guys. Now we can focus on selling our capabilities on top of this great product.

Being a young and evolving product, there were plenty of breaking news items delivered during the conference.

It was great to hear the announcements on Professional and Elite editions. Future announcements like the implementation of a file management provider will be a great boost to our enterprise clients. It will also open up an opportunity to develop on top of SharePoint as we see many of our customers opt for SharePoint for document management and collaboration.

The announcement of a deal on the inclusion of the Telerik RAD controls was very welcome. We’ve used Telerik from the beginning so it was nice to see we are making the right decisions. What that actually means is that user experience and the extensibility of modules will taken to a new level.

Integration of Google Analytics and segmentation of traffic is also a welcome addition.

There was plenty of lively debate on what the acquisition of Snowcovered means and what the community felt DotNetNuke Corp needed to do to clean it up and further raise module development standards. We'd like to see some standards and a QA process before modules are listed there. Even if that means the cost of individual modules goes up.

Probably the most contentious issue discussed was licensing and it was interesting to see the different perspectives on the chosen “per instance” model. Those running DNN across large server farms were understandably concerned and those running very large single instance, multi-portal implementations were very quiet!

With two DNN tracks running over the three days and six sessions a day, there was plenty of information being dispersed. We even snuck into a couple of Sharepoint sessions running as part of the larger ASP.Net Connections conference which was helpful in understanding the relative strengths and differences of both platforms.

All in all, an event well worth attending, and one which will pay for itself over the coming year through new found contacts and knowledge.





Go to this post's page at www.zinepal.com and get the PDF file or perform various sharing actions.

Friday, 6 November 2009

How to Choose a DotNetNuke Module From Snowcovered

DNN MODULE SELECTION PROCESS

INTRODUCTION

One of DotNetNuke’s greatest attractions is its modular architecture which literally allows you to "plug and play" almost any kind of functionality from Ad Rotators to YouTube plugins. Whilst we could develop all of these tools ourselves, there's really no need when you can pick and choose from the thousands of ready-made modules available, at low cost, through the Snowcovered online market for modules and skins. It's DotNetNuke’s version of the Apple App Store.

By and large, the quality of the modules is pretty high, but in our field where we're integrating DNN into large Enterprises, we need to make sure that the modules we implement are best in class.

To achieve this, we follow a fairly rigorous process to identify, filter, test and implement only those modules that meet our criteria. I've set out below all the points that we consider when selecting a new module. The points cover not only any technical issues but also help you identify how much work you'll need to do to install, skin, set up, train and support a module and your site editors.



1) REQUIREMENTS

It sounds pretty obvious, but before you even start searching Snowcovered, you need to capture the key requirements. Don't forget that what your client is asking for may not be want they want and probably isn't what they need.

• Brainstorm all of the key requirements

• Categorise them: features that are essential, and those which are nice to have.

• Consider where the module will be used; on what pages and how do you want it to look. Does it need to tuck neatly into a narrow column, or is something full width acceptable?

• What will it be used for? For example the most popular use of the FAQ module is to create nice lists of expandable content to save on screen real estate - not to help users find answers.

• Who will be using it and what will be their technical level?

Search Snowcovered for ideas and shortlist. Think laterally, as modules may be categorised or labelled differently from what you would expect. For example, you will find many 'Form' modules provide survey functionality.

Look more widely. Go and ask the DNN community on the DNN forums or on Twitter (hashtags #DNN, #DotNetNuke) if they know of any modules that can help. Some developers don't list on Snowcovered - For example Ventrian Systems has excellent news and document management modules - but doesn't sell them directly on Snowcovered.



2) THE DEVELOPER

Assuming that you are in business for the long haul, you should favour modules from developers who are committed to continually improving their products and who’ll be upgrading their modules as DNN evolves. It’s a hard conversation with a client when you have to pull a module that used to work because the back end is upgrading.

Consider:

• The ratings and feedback they have received on Snowcovered

• How long they have been in business?

• Are they a professional developer or a hobbyist?

• How many modules have they produced?

• Are they continually issuing new versions and improving existing products?

• Is there an on-line demo you can play with or a library of screen shots?


Support:

• Is there a forum?

• Is there a help desk system/tickets? (if they sell through Snowcovered, then you'll be able to raise tickets through them)

• Is there a user guide or training available?



3) THE MODULE




• What is the balance of complexity versus functionality - does it do what you need it to do? Does it do too much which makes it hard to use?

• Will your end user be able to manage it or does it require 'super user' or 'mega user' skills?

• Search web and DNN for references to the module (or module category) for any compliments or complaints.

Twitter the question (with hashtags #DNN and #DotNetNuke) to see if anyone has any experience with the module.

• Is there a trial version available?





Design:

• Does it look good?

• Look at the module.css file - does it have custom styles and colours that aren't overloaded by your skins?

• Does the module offer template functionality under module settings to allow you to change the layout? Can you change the default template that's available to users?


Testing:

• When the module is installed in DeskTopModules does the module folder name have a "." (e.g. "\desktopmodules\BigShot.Developer" ) in the folder install path? If you are going to run this in an older network envirnment your CSS and javascript files may not load in the client browser.

• Are you running this in a a multi-portal environment? Test it within a number of children - some developers don't cater for Portal IDs.

• Consider browser compatibility, XHTML compliance and accessibility requirements and test against the W3C validation tools.

• Does the module have .resx files for localisation? Whilst you may not be looking to add other languages, if the developer's first language is not English, you may want to clean up some of the module's labels.

• If design (styles etc) is hard coded in a DLL it makes it impossible to clean up later.


Database:

• Look in the PA ZIP and open up the script files in Notepad. Has the developer used tokens for the database prefix and object owner? Don't hardcode DBO as the default database object owner - some DBAs won't allow DBO access to production sites inside Enterprise networks.

• Has the developer included uninstall database scripts? If the module requires no changes to the database (i.e. it has no script files) the install/uninstall risk is low because no structural changes are taking place.


Programming:

• Does the module have any dependencies on other components? For example, we use the Telerik RADcontrol suite extensively and recently had an issue where a module installed an older version of the primary Telerik DLL.

• Is the module searchable? Does it integrate with DNN search? Does it allow search engines to crawl its content? You will want to look at how it redirects pages, its use of cookies and javascript and how it manipulates the URLs.

• Is the module exportable (iPortable)? This is a fantastic feature that allows you to easily backup a module’s setting and content and/or re-use that content elsewhere. The code DNN "Copy Module" functionality relies on this. Can you syndicate content out of the module using the DNN syndication features, or does it have its own?

• Once installed, look at the web.config and make sure you understand the implications of any changes it has made.

• Does it install or use any directories other than under desktop modules? (e.g. App_data or folders e.g. Telerik.)

• Look at the size of the install.zip PA file - if it is too large you may have time-out issues uploading the module.

• Look at the .dnn manifest file - is the friendly name really friendly and will the site administrators identify the module from its name? We prefer to rename modules based on their functionality. For example, it's not really useful if a user looks at the module list and sees "GeeWhiz ezeMap" - we'd change it to "Google Maps".

• Is the .dnn manifest file complete with license information, version (that matches the DLL) and help links?


Installation:

• Can you use the module more than once on a site? For example, if you use the core blog module on multiple pages it will reference the same content. (It is PortaslID and not ModuleID based.)

• Can you put the module more than once on a page? We implemented a ratings module once, but then the site owner wanted to rate several articles on the same page and it didn’t work.

• File uploads and permissions: if the module uses its own file manager and upload tools, check that it is integrated with the DNN file manager and its permissions.

• Does the module use a text editor? If so, is it using your default editor or its own?

• If the module sends out emails – are the templates customisable?

• Look at where module settings are – does it include a section at the bottom of the module settings, or does it create a separate entry in the module action menu? Will the users find where to administer the module?

• When the module is installed, how many modules are created? Are they all needed? For example, do you really need that "Top5" companion module?

• Is the module easy to set up on a page? Some modules, like the blog, add about 5 modules to a page - this can be a daunting process for a user!


Licences:

• What are the terms? (per child; per DNN instance; unlimited; etc)

• Cost - is it cost effective?

• Does it require a licence key? (We have had issues with a module which required text license file in the BIN directory – every time the server was re-started, we had to re-install the licence.)

• Are upgrades free for point releases? Or do you only have to pay for major releases?


Hopefully module developers will consider these points and, by following them, will raise the quality of DNN modules - for the better of the whole DNN ecosystem.


Go to this post's page at www.zinepal.com and get the PDF file or perform various sharing actions.

Friday, 25 September 2009

Module Categories to help you plan your DNN site design

There are a bewildering number of DotNetNuke modules to choose from, some good some bad some just weird. So how do you choose a sensible set to give to your editors?  At Glanton, We have been implementing DotNetNuke for over five years and in that time we have tried many modules. Some have stood the test of time, some have been discarded and many have evolved through upgrades and newer versions.  If you are looking to implement DotNetNuke or are looking for an implementer to help you then you might want to think about your module set by considering the following categories.  You'll want a mix of modules across all of these categories and I've suggested and highlighted some that work for us and our WebAdvantage implementations. Some modules straddle categories of course but in terms of the user's experience I think they work.

Content Management
'Stuff on the page' in other words. Mainly static, read and jump content. If you want a brochure ware site you probably don't need to go far outside this category.

Text/HTML
This is the daddy. You'll spend the vast majority of your time in here.  Editing text, adding photos, links and doing layout with tables.  The standard editor from DNN is ok but the RAD editor from Telerik is the one we choose. It's well supported and well documented.  You could build a very good site using this and this alone.

Links
Links are well handled in the RAD editor but the DNN links module has one feature that keeps it in our toolbox - the drop down option.  This means you can save space and tuck all your links in a small space. Lots of our clients use this feature to have a 'Quick Links' feature that they put high up on the page then make it available on every page.

Aggregator
This module gives you the ability to put tabbed content within a page.  You'll have seen it on many websites, DNN or otherwise. We use it ourselves on glanton.com.  Use it to manage content on a page. Group themes or related content on tabs.  You should consider it as an alternative to child pages. Since all the tabs load at once it avoids a server page refresh. It's much more satisfying for your viewer to use.

FAQs
For me, this module's name masks its true potential. Sure it does a great job as an FAQ manager; you can categorise, expand and have full control over numbering and ordering but it is also a great way to organise your content on the page.  Think of it as a 'heading and detail' module and you'll get the picture. Since both the 'Question' and 'Answer' are built with your Text/html editor, you can put a prĂ©cis or tease in the 'question' which will reveal the full content, detail or 'answer' when clicked.  The settings allow you to switch off the 'Q' and 'A' and numbers so that to your user it would be like reading a list of summaries, the full content only revealed if they want to see it.  Like the Aggregator it all loads at once making it quick and enjoyable to use.

News/Blog
I'll be honest, we made a bit of a mess of this for a while. We tried 'Blog' modules and 'News' modules. Some were feature rich but clashed with the skin and some needed a lot of admin support. In fact, there is no real difference between a blog entry and a news piece. They are both 'articles' and need a time-stamp attribution, categorisation, archiving and the facility for the reader to comment. Once we realised that we settled on the Ventrian 'News' module and it has gone down very well with our users.

Site Map
A standard offering from DNN but essential to have one on every site I believe.  I gives an 'at-a-glance' shape and size view of the site and it's a quick navigation aid.  If your site is very big but with clear sections, then use the 'root' feature to give a local map to that section. We usually drop a link to the site map high up on every page.

Visual Appeal
It's a visual age and you never see a webpage without a picture so what else can be done to excite the eyes of your visitor, here's some ideas of modules and other tools.

Image Hotspots
The RAD editor has a nice feature to add multiple hotspots on an image, it's easy to use and great for diagrams, flowcharts and schematics.

Image photo galleries
There are many, many image galleries, rotators, carousels out there. They can be fun but don't have then spinning or changing too fast and always put controls so that the viewer can pause and control the flow.  Check out flashden.net for lots of flash galleries that you can incorporate on your site.

Document viewer
Links to documents are fine but it's much nicer to show the document open and browsable. Print2Flash does just this.  You can zoom, search and page through docs in a natural way. Just convert your doc to flash then embed using your editor.

Video
Everyone want clips these days and why not?  But movie files can get big, unwieldy and they don't perform well running straight from your web server.  If you are serious about streaming then use a streaming service. We use vzaar.com.  You get a choice of movie sizes (width and height), borders and the streaming is very smooth.  Contact us if you'd like us to host your movie.

Flash
Mentioned flash a couple of times already but don't forget the interactive flash stuff.  Flash is very powerful in getting your point across. Use a professional flash developer (we can do that for you) and pay attention to performance and duration. It's easy to drop onto your page and still has a lot to offer.

Integration
Brochure ware only goes so far, especially in a corporate Intranet environment. Your visitors will want to integrate content from other corporate repositories, sites and applications to sit inside your portal.  Here are some easy ways to do that.

Document Manager
This has been a tough one. All businesses have a problem with document management but there just doesn't seem to be a module out there that strikes the balance between functionality and simplicity.

Bring2Mind and Xepient have good solutions but Ventrian have a fantastically simple, easy to use File Links module.  If you use SharePoint in your organisation remember you can iFrame to the document lists to bring them into your website.

iFrame
Standard DNN. We like iFrame it's easy and with a bit of imagination it can really pull things together.  You can make web based apps sit in your site's context and stop your visitors having to jump somewhere else. You can expose nuggets (like share prices) from other sites if they are in their own frame (url).  It would be nice if you could iFrame resource not URLs (e.g. network shares).

RSS
By this I mean pulling RSS feeds onto your site, not syndicating out. Nukefeeds from Orizonti is what we use. It's good for it's caching, templating and aggregation. My favourite RSS source is Google News. Craft the search to your needs then click on the RSS button.  Yahoo weather is also nice because it feeds through the weather icons.

Interactivity
Users expect to interact with sites and by getting them to do some work you'll get more out of your investment - ans so will they.  These are some of the ways to make a site visit more of a two-way process.

Events/Calendar
Another standard DNN offering. The team have done a great job.  It is feature rich: enrolment, Outlook integration, multiple views and rich text editing of the content.  If you want a hands-off way of handling your events or training sessions then give this a try before you buy anything else.

Wiki
A niche product and it takes a bit of setting up but in the right hands it works very well.  Great for knowledge capture especially in specialist areas (don't bother with a general purpose implementation, Wikipedia's got that covered!).  

Forms and Databases
Formmaster from Code5Systems is the Swiss army knife of modules. Has a great balance of being feature rich but not too complex. We hand users for the first form and then they manage it themselves  One client built 40 forms in 2 weeks for their Intranet site.  For simple parent/child databases we like Indoo Grid although the documentation leaves a bit to be desired.

Survey
The Rhema SuperSurvey. Was a very good module but has evolved into something so feature rich that it's become a little hard to train users on.  It's still probably the best out there but its current incarnation is another case of the balance between functionality and simplicity going wrong.

LMS
We are just about to launch a major implementation of an LMS and we are using the Accord module from Interzoic.  It looks easy to use and their site is full od info and video so we are feeling confidant!  As for content we'll be starting with the Articulate suite maybe enhanced with a bit of Camtasia.

Hope you found this guide useful, I'm sure you have your own favourites, if you really feel I'm missing a trick then let me know. You'll find my address at glanton.com




Go to this post's page at www.zinepal.com and get the PDF file or perform various sharing actions.

Monday, 21 September 2009

Impersonation in DotNetNuke Intranets

We (Glanton) specialise in implementing DotNetNuke ("DNN") as an intranet application for large enterprises and vouch for the fact that it's a very different animal from setting up your standard internet facing DNN site for clients.

I was surprised at the complexities introduced when impersonation is enabled on a DotNetNuke site and hopefully our experiences and thoughts below will help others. I've tried to keep this as simple and non-technical as possible.

When working inside large enterprises, you are not working on your infrastructure; you have very little control and you don't get admin rights to machines to set up as you like. Furthermore you have to adhere to a bewildering array of branding, security, legal, infrastructure, change control, project management and technical standards - which are often quoted but seldom found!

And, of course, you are running across a network - and that means that everything which DotNetNuke does has to be set against the backdrop of the identity in which it runs within that network.

If you are running DotNetNuke as a simple, low level 'brochure-ware' site using DNN authentication, it's simple. DNN will run quite happily in the context of the ASP.NET worker process doing what it needs to do inside its own server walls and never having to venture out into the big bad network.

However, what if we need to implement Active Directory authentication so users can manage DNN using their own familiar network accounts? Now the ASP.NET server account has to go and ask the Active Directory server ("AD") if Joe Bloggs is in AD (identification); if he is indeed Joe Blogs (authentication); what his phone number and email address are (profile management) and what groups he belongs to (role management). Because the ASP.NET account is local and specific to only the server that DNN is installed on, we have to get someone else - that AD knows and trusts - to ask for us. We have to enable impersonation.

Enabling Impersonation

Impersonation is enabled two ways:

1) By adding to the web.config file, the section

 <identity impersonate="true" />

This now means that when Joe Bloggs opens up our web page, DotNetNuke will run under the identity of Joe Bloggs. And because he is a network user, he can access Active Directory and so everything will work just fine - or so we think!

Alternatively, we could add to the web.config
<identity impersonate="true" username="svcUserName" password="P@ssw0rd" />

and actually specify the identity of the user that our DNN should run under instead of the user visiting the site. Rather than using an existing user account, for which the password may change or the user could leave the company (and then the site will simply stop working), we should go and ask the AD admins for a "service account". These are a system type of user account for which passwords can NEVER be changed and which generally have a very low level of access inside of the network (proxy servers, firewalls and AD read permissions) so can't do much damage.

Most Enterprise service desks will prohibit you from adding the service account password in clear text inside of a web.config so you'll have to either encrypt the password or get the service account password added to the server registry and retrieve it through code. This is to stop site users (not network admins) who may have root access to the site, from reading the service account details.

2) By code

A method I prefer is that, if our module needs to go out to other servers on the network, we add a routine to our code that impersonates a service account within the context of that code or module function only. This means we are not locked to the identity of the user set in the web.config. Generally I look up the proxy username and password that is stored under host settings, but the Active Directory authentication provider does it by storing this information in the module settings table and encrypting the password in the database.

The reality is that most DotNetNuke installations will set because of the extra effort of encrypting and retrieving passwords (or blatantly exposing service account passwords in clear text).

Microsoft's MSDN library has lots of technical information on how to use impersonation and delegation in ASP.NET 2.0.

Implications of Impersonation
OK great - we've done what the manual says and we've got impersonation working. Job done? Actually no - now the fun starts when you start getting calls from users saying the file manager is broken, RSS feeds don't work and performance has gone up the pole. Ooops!

File Access
For simplicity sake, assume we set impersonation=true but have not specified a user account so that that DotNetNuke assumes the identity of the visiting user - Joe Bloggs.

If we impersonate Joe Bloggs and he tries to upload a file (or even read the folder contents) through the file manager, it will fail. This is because Joe Bloggs does not have specific read/write/delete file permissions on our web server. Firstly, who are we going to give permissions to? We certainly don't want to give the generic groups "All Users" or "Everyone" permissions because that means that anyone who did manage to get access to the server could cause havoc. Our best option is to give read/write/delete permissions to the "Authenticated Users" system role. Anyone accessing the server would have to be network authenticated first and my network admins tell me network users can't map a direct drive to the share because sharing has not been enabled. So I'm feeling a little more comfortable but I'm still a bit twitchy about giving delete permissions for DNN system files.

So what do we give "Authenticated Users" access to? In summary, I give authenticated users users read/write/modify access to everything and delete permissions over the contents of the /portals folder.

I once fell into a trap where I initially just gave "Authenticated Users" permissions over the portals folder. Because I was the application owner and had been given full access to the share to set things up, I was able to install new modules, read pages (that were cached to file), use modules which write data to bizarre places (like Indogrid which writes to the app_data folder) and so on, and everything worked fine for me. But of course, as soon as it went into production, the phone started to ring with users who had different permissions to me. In one instance, we had to extend permission over the ASP.NET cache folder as well.

You also need to consider the implication of changing server permissions if you are working in a three stage DEV/TEST/Production environment - these server permissions have to be applied to all sites - and some support admins may have a problem with opening up permissions on a production site.

Databases
We've recently had to move into an enterprise environment where we had to use Integrated Security (i.e. a 'service account') to connect to a database server. For whatever reason, the Site admins could not set up a direct connection to the DB server so we had to use impersonation. This means we had to change the permission sets on the service account. And to make matters more complicated, the DB admin insisted on a separate service account for each of the three DEV/TEST/PROD databases. A mission to manage and co-ordinate. And then they complain that you can get hosted DNN out on the web for $50 per month!!!

RSS
If you are trying to access an RSS news feed from another web server on the network you are going to have a problem - even if you have enabled impersonation. The server that you are reading from will have to grant your impersonated user permissions to read its data. If you use a service account, it's easy for them to add. But they may not be so keen to open up Read access to "Authenticated Users" on their server. This is a difficult concept to explain to a user who is used to seamlessly accessing content across their intranet.

In Conclusion
I try and avoid impersonation like the plague and have written out of the DNN AD provider any calls that rely on impersonation. I stick to specific DirectoryEntry type searches where we can specify the service account and password stored in DNN. As systems integrators, it cuts down our work tremendously by avoiding all red tape associated with requesting service accounts and permission changes on boxes.

If you do use impersonation, hopefully I've shared with you some of the issues you may encounter - but not have foreseen. Let me know your experiences?




Go to this post's page at www.zinepal.com and get the PDF file or perform various sharing actions.