[mturkington]

We're in the midst of our website migration off Convio to BBNC (and friends). I've appreciated the success (and failure) stories found here on the BUS, so I decided to write up parts of our story as we go along and share them for posterity. Hopefully something in here is helpful for someone else either considering the jump or going through the same thing. So, without further ado, here's comes the first edition.

[mturkington]

Background
We’re a medium non-profit in the relief & development sector. We use RE extensively in-house, but Convio on the web. This has proven problematic as the “data sync” Convio talks about doesn’t really work. My boss has really high standards for data integrity, and a “sync” that just blindly writes to RE isn’t going to fly. We have a hacked-up import process that takes the gifts from Convio and translates them into an RE import. This puts a lot of work on our gift processing people, plus we don’t have any of the advantages of integration: constituents can’t see/manage their profile online, no giving history, etc. It’s pretty annoying.

We’ve been on a big integration kick, reducing the number of data stores in the organization. Almost all of our standalone custom apps for tracking things have been rethought to use functionality in RE. A big selling point of BBNC is that we don’t have yet another database (as with Convio), with another store of constituent data.

My background, so you know what angle I’m coming from, is IT. I have over ten years of web development experience (self-employed, so a wide variety of projects), but mainly specialize in systems architecture. My concerns are for the stability and availability of our systems, integration between our systems and their efficiency. Coolness helps, too. As does saving money. I’m a reluctant RE admin and certainly NOT a development/finance type. My web background is a big part of being on this project, but there are two other individuals in our organization responsible for the content of the website, not me. They will be the ones interacting with the site administratively day-to-day.

Choosing a CMS
Ok, so it’s probably clear that we went with BBNC (given this thread and all). As we were going through the sales process, however, I was struck with how bloated and, well, crappy the BBNC CMS is for the content authors. Creating pages was funky and time consuming. They layout wasn’t intuitive. RE integration is a major plus (and a “must have” for us), but the CMS side of BBNC was going to add a lot of work to our communications team. Not ok.

So we embarked on a project to find another CMS to potentially use WITH BBNC. The thinking was that if we could find an outstanding CMS that integrated nicely with our other systems and was insanely easy to use, we could build the bulk of our site in that. The only pages we would build in BBNC would be in support of the RE-integrated functions (donations and profile management). Kind of a crazy idea, I know, but I believe in finding the best tool for the job. BBNC is best for constituents, but not good for content providers. And, as many people on the BUS have pointed out, kind of inflexible.

My search was initially for .NET CMSs. Since BBNC is based on .NET, that would give us the most opportunity for integration, should we need to. I was looking for something highly customizable and flexible, but intuitive and easy to use for the content authors. We sat through sales presentations for products ranging from a couple hundred dollars to tens of thousands. It was a painful process.

In the end, we landed on a product named Sitefinity, made by Telerik (if you’ve done much with .NET controls, you’ve probably run across them). This fantastic product satisfied my requirements. It’s very easy to use for the content authors (and even somewhat similar to Convio to help with the learning curve), it’s infinitely customizable, really fast, standards based, cheap….pretty much everything BBNC isn’t. Our communications people were impressed with it, then shocked when they found out it was the cheapest option. After non-profit discount, it was around $700. They have a “community” version that’s free (!), but doesn’t have support. They do have a very strong community (second to the BUS, of course), and the staff are active in the forums. It can be faster to post a question there than open a support ticket – but their support is good, too. I know this is supposed to be about BBNC, but I just want to let you all know how happy we are with this product (and it plays a big role later). We also decided to wait until BBNC 5.5 came out. More on that later, too.

Hosting
Having made the decision to go with a hybrid Sitefinity-BBNC solution, we got to work building the infrastructure. Some of you saw my posts a while ago about hosting options for BBNC. For those of you just joining us, there are four possible configurations:

1. Host the whole thing (BBNC + RE) at Blackbaud.
2. Host the whole thing in-house.
3. Host BBNC at Blackbaud and RE in-house.
4. Host BBNC somewhere (colo, etc.) and RE somewhere else (in-house, Blackbaud, etc.).

Here’s the deal – hosting is hard. If you’re a small organization, you can probably pull it off in-house and not worry. If you have good stats on how many page views you get a month and about how big a page is, you can calculate out your bandwidth required. You have to be careful of simultaneous connections, though. If you just have a T1, you’re not going to get a lot of people on there at once. Talk to your current ISP/host and see if you can get some metrics on your bandwidth utilization (mainly the peak number) to help you figure out your options. If you need to pull in a fat pipe to host your website in-house, that may be a cost prohibitive option for you. You also become responsible for keeping the website up. No vendor to scream at when it goes down. That’s option #2.

RE and BBNC like to be close. There’s a lot of talking going on between the two, and, according to a coerced response from Blackbaud, if BBNC ever can’t hit RE, your site is hosed. This is the major risk in separating the BBNC and RE servers (as with options 3 & 4 on my list). If you ship the whole thing off to Blackbaud (#1), you get the best performance for the web, but your internal RE uses will suffer greatly as they have to run RE remotely. Not fun.

Another complication for us comes with being a disaster response agency. We normally do around 30,000 visitors a month. When a major disaster hits and the media decides to run with it, we often get a lot of airtime. Consequentially, we get a lot of people trying to make donations (our bread-and-butter). A lot will do this on the web. We’ll easily do 30,000 visitors a day for up to two weeks with a Katrina or tsunami-sized disaster. So the ability to quickly scale up is crucial. (side note: we were with NetSolutions back in the day, and it crashed during the tsunami)

In the end, we decided the preferable option was hosting both in-house. We were not willing to ship RE off to Blackbaud, and were too worried about connection problems between RE and BBNC if they were separated. Also, you have a lot more flexibility on your own server. We worked with our ISP, who is both local and a long-time supporter of ours, to pull in a fat pipe (10MB – up from a T1) between us. We’ll let you know how it goes, but we think that will be adequate to support our traffic requirements for hosting in-house.

Our architecture is made up of one really (really) beefy database server (single instance of SQL server for both RE and BBNC) and a front-end web server. I’m working on a load-balancing scalable farm idea (more on that later), so the option of adding more front-ends is good.

[mturkington]

Looks like this may turn into a weekly feature. We're about 12 weeks out from (projected) launch.

Install
I wasn’t able to work with Blackbaud during the install, and handed the engineer off to a co-worker. I wish I would have stayed involved! After the fact, I learned there are multiple components to the BBNC install, four of which I care about at this point: BBNC application, BBNC database, plug-in web service, and RE web service. For the uninitiated, they’re pretty much what they sound like. The BBNC application is the actual CMS that renders pages; the BBNC database is the back-end data store (not to be confused with the RE database); the plug-in web service is what the BBNC RE plug-in hits to get its data; the RE web service is how BBNC communicates with the RE database. If you’re new to web services, they’re essentially a specialize web site that runs on a server. The service receives specially formatted XML requests that it then processes and sends the results back as XML. This enables BBNC and RE to communicate over standard HTTP and keeps you from making Swiss cheese of your firewall.

Blackbaud installed the database on our database server and the rest of the roles on the front-end web server. So when BBNC needs to talk to RE, it makes a call to the web service living on itself over HTTP, then the web service goes and gets the data from the RE database (on another server) over whatever .NET library Blackbaud decided to use for database access. This is not the proper way to do web services, and almost completely defeats the purpose. Communication between servers is not over HTTP (presumably you have port 80 open between them already), so the web server needs to talk directly to the database (you’re gonna have to open some firewall ports). More importantly (to me), you put the burden in the wrong place. The web server is doing database calls instead of the (much) more powerful database server. Additionally, if you want to add multiple front-ends, you don’t want each node to have its own instance of the RE web service. That would result in a ton of connections (and not leverage the whole point of web services). Ideally, you have the web service living on the database server (or, if you’re doing a really large deployment, you could have a whole server set aside for this mediation) and all your front-end servers hit that service. And if you leave the web service on one of the front-end servers, all other front-end servers would talk through it to get to the database, effectively eliminating the benefit of load balancing.

Also, consider this: the plug-in web service (which the RE client uses to talk to BBNC) communicates with RE via the RE web service. So you have a client, running RE, that clicks on the NetCommunity plug-in. This calls the plug-in web service (on the web server), which in turn calls the RE web service (also on the web server), which then queries the database. With both of those services on the database server, the RE plug-in would hit the database server, which would hit the RE web service (also on the database server), which would query the database. No web server involved. Why should you put a load on your front-end web server when someone needs to run RE?

Note: if you’re running a distributed environment with the BBNC database and RE database separated across different servers, you will want to run the RE web service on your RE database server and the plug-in web service on your BBNC database server. A client using RE with the BBNC plug-in will hit both web services on both servers to get its data. But leave the front-end server out of it, if you can! Unless they’re all one server in the first place, in which case you should probably rethink your architecture anyway.

Moving those roles around isn’t hard, but it’s not easy either. You can uninstall the roles from your web server and install them on your database server through the BBNC installer. I ran into a major installer problem using the packaged installer you download from Blackbaud. It unpacked into a temp directory, which was deleted at the end of the install. So when you go to add/remove programs to modify the installation (or run setup again), it looks for the source in that temp directory. Needless to say, it can’t find it and the installer blows up. Workaround: when the installer blows up, go to the directory it lists. Copy that folder out so you can use it later. Then go hack up your registry so the installer source is set to the folder you just saved. You might need to use Microsoft’s installer clean up utility. Comes on, Blackbaud, make installers that work. Anyone who’s tried to deploy RE patches administratively knows what I’m talking about….

So you can install these roles on the database server, then go into the configuration section of NetCommunity and change the web service URL. IMPORTANT NOTE: the RE web service is 32-bit ONLY. The plug-in service can run in 64 bit. We have 64 bit servers, running ASP.NET natively in 64 bit. The RE web service will not work in this configuration. It MUST be installed into a 32 bit ASP.NET application pool (server OS doesn’t matter). You can toggle between bitness (yeah, that’s actually the term for it), and you can run 32 bit ASP.NET on a 64 bit OS. But you CAN’T run mixed 32 and 64 bit application pools in one IIS instance. So if you have an app on your database server installed in 64 bit (like MSSQL Reporting Services), it’ll hate you. The only way around this is to use IIS 7 in Windows Server 2008, which lets you mix bitness. Yes, BBNC runs in Server 2008. No, it’s not a headache to get it working. Things are just in different places, and if you don’t know Server 2008, it might take you a while to find things. The docs also say you have to use mixed mode authentication on SQL server. In 5.5 it can do integrated authentication.

Also, TEST EVERYTHING before you sign off on the install being complete. We were told everything was installed and working, then later found out the emails and syncing between RE wasn’t quite going. Ask to see it all in action.

[paulmorriss]

I wish we'd known this stuff before we installed BBNC!

[sowacs]

Quote:

Originally Posted by paulmorriss

I wish we'd known this stuff before we installed BBNC!

It's not nearly as bad as mturkington makes it seem. I can understand the frustrations, though.

Quote:

Originally Posted by mturkington

...

!

The installation that Blackbaud performed is the simplest approach, and generally works just fine. Websites will always access a database, regardless of the presence or absence of webservices. And the caveats about having a webserver and database server sharing the same hardware applies as to webservices as well as to websites - they have the same infrastructure. As for the installation files themselves, you can unpack that manually without having to jump through the described hoops.

Ideally - well... as with anything "real", there is all kinds of room for improvement.

What's needed is something I might call a "Blackbaud application server" on the internal enterprise network (not in the DMZ). This would host the primary RE installation point (including the BMC, if setting everything up from scratch), the RE client installation that the RE7 webservice needs, the RE7 and Plugin webservices, and whatever else supports Blackbaud products. The idea is to segregate these resource needs from both the webserver(s) and database server(s). This server could well be used for similar purposes for other products.

There should also be two database servers, one dedicated to supporting the website, including BBNC and any other website related packages that may be installed. You don't want to share website data provisioning with enterprise application data provisioning. The RE7 database belongs on the enterprise database server. These database servers are also on the internal enterprise network (not in the DMZ). Note that no applications should be installed on any database servers, web or otherwise.

So now, the webserver(s - if a farm) needs an internal firewall hole to the website database server. The application server (just one, or can be load balanced separately rom the webserver(s)) accesses the database servers as needed, and, being a full member of the enterprise domain, can be secured as needed without incurring firewall concerns. The database servers are free to use their resources unfettered, as is the application server.

What's clear with this arrangement is it requires more hardware, and more BBNC installation points, than the default installation that Blackbaud performs. Well - only one extra machine is needed for the application server, and my bet is that most organizations already have a machine playing that role on their intranet. And then there's always the possibility of using virtual machines to help with some of this (another topic, another time).

[mturkington]

Oh, you’re right. It’s not BAD, per se, but it does strike me (in retrospect) as a little lazy. At no point did they talk to us about the BBNC topology or our existing infrastructure – they just went with the one-size-fits-all install. For what they charge for “consulting,” they should actually consult! Don’t get me wrong, I’m not an AntiFanBoy here (no offence, AFB). Just trying to balance out the sales pitch with reality. I’m a big supporter of BBNC for organizations using RE; I just want to see people prepared and thinking through their implementation. These are the details I wish Blackbaud talked with us about before we started.

I’m going to disagree with you on the “two database servers” comment. In most cases, I think that’s unnecessary, but it sort of depends on some broader configuration decisions. From a hardware standpoint, we intentionally purchased a substantial database server to allow us to centralize all our data stores. If you were working in a clustered high availability environment, you would have many pieces of hardware, but one virtual (though not virtualized) SQL server with SAN backing you would present to your network. From a security standpoint, you can use separate instances of SQL server if you’re worried about authentication/authorization crossover problems. And with the advent of IPSEC and the dynamic firewall options on Server 2008, the push really is towards centralizing resources on less hardware without sacrificing security. You no longer need to provision multiple pieces of hardware to maintain a multi-zone security model.

The web service issue comes down to how you want your database server talked to. Do you want direct database calls/data travelling over your network or XML? We chose XML. Others may choose differently. Personally, I would rather open a port on the database server to talk SOAP and be able to monitor that (the security Blackbaud builds in is sufficient) than allow direct SQL calls to be made by the web server. That way you are only exposing a limited set of functions. Remember, the web service talks to the database server DIRECTLY and can really ask it for anything. But the web service only receives a certain, pre-defined list of operations. You can go to http://server-name/re7service/masterservice.asmx to see the list. In my mind, it’s a far smaller security risk because the requests must be so structured and specific, along with providing credentials. So if you leave the RE7 web service installed on the web application server, you’re allowing it to talk directly with your SQL server. If you place the RE7 web service on your SQL server, you only have to allow the XML SOAP requests to go through.

In your scenario, you have a front-end web server (WS), a BBNC database server (NCDB) and RE database server (REDB). If you have the RE web service (REWS) installed on the WS (default), you have to allow the WS to communicate directly with the REDB. If your WS were to be exploited, someone impersonating BBNC could gain full access to your RE database. Conversely, if you have the REWS installed on the REDB server, you still have to open a single port, yes, but you’re limiting the requests that can be made against your database. Yeah, you can argue running the REWS requires IIS and that introduces security risks (even though you can IP limit it to only receive SOAP from the WS), so we may just have to agree to disagree. :-)

And, yes, please don’t install REDB and BBNC on the same server.

Anyway…I don’t want any of this to sound like The Way to do BBNC (or any website). I’m just reporting what we did, our rationale and decision-making process. Each environment is different and will have different requirements. The bottom line is think about your security and how you will mitigate the risks involved with linking a website to enterprise data.

[sowacs]

To help clarify the discussion, a few rough deployment diagrams:

1. Default deployment by Blackbaud: everything on the web server, one database server;
2. Deployment described by mturkington: web services on the single database server;
3. One alternative deployment: separate applicaiton, web and database servers.

There may have been some minor misunderstandings in the above discussion.

[Peter Gulka]

Quote:

Originally Posted by mturkington

And, yes, please don’t install REDB and BBNC on the same server.

Why not?

[mturkington]

I would offer two reasons:

One, performance. Both database servers and web servers are resource-intensive applications. Unless your user base (for both database applications and web site) is extremely small, you will see performance problems running both on one box.

Two, security. If someone is going to compromise your network, it will most likely be through your web server. It's the most externally visible server on your network, and often web software has the most security flaws. So WHEN that box is compromised, do you want them to be able to open your database right up? With it on another server, you have another layer of security for them to pass through, limiting the damage of a security incident.

[Peter Gulka]

We're getting ready to fully evaluate BBNC as an option starting in mid-November so this thread will be invaluable for my IT Director.

[thrasher141]

Wow, what a great thread. Thanks, mturkington, for sharing your experience. I especially liked your first post and relate very much to it - that is similar to how we've approached it. I could tell in the sales/evaluation process that I didn't want BBNC to be our CMS, so we did what you did - used it in a limited deployment for only the "transactional" pages that need to communicate with RE, like giving and profile management. The rest of our website is managed in house with a custom CMS. And they are actually two different webservers. The BBNC webserver is in house and the other one is hosted with a hosting provider. It's a LAMP environment and I'm evaluating CMS options for an upcoming redesign...such as Joomla, Drupal, and Plone. BBNC simply is not powerful or flexible enough or easy enough to work for us.

The downside to this method is when you want to redesign the site or any shared component (navigation menu) you have to do it in both CMSs.

Mturkington, are you still satisfied with Sitefinity? And do you recommend having .NET experience before using that product? That's what would be scary for me, I'm not a .NET guy at all. I've tried a bit with BBNC custom parts but the learning curve is steep. That's what I love about PHP...it just works!

[mturkington]

Thanks! Glad to hear we’re not the only ones doing a hybrid implementation. You’re right about the difficulty, though, especially with updating templates. I was really disappointed to see that BBNC isn’t a “.NET CMS” and more of a “CMS written in .NET.” It doesn’t truly use the full .NET feature set – things like Master Pages would be invaluable for keeping multiple platforms in sync. About the best you can do now is fake it with include files reference by both sites.

I don’t want to get too OT and start talking about non-Blackbaud products (and incur the moderator’s wrath/start a flame war), so if you have a lot of questions, maybe contact me offline. But I will offer this as a generality: yes, we are still happy with Sitefinity. No, you don’t need to know .NET. I’ve dabbled in it before this project, but have been trying to pick it up more so I can write custom parts for both products. Hasn’t been too bad. But you don’t need to know anything to get it installed, working and publishing pages. Only if you want custom parts (and, really, there’s so much it can do out of the box…).

The one big advantage I see in going with a .NET product over LAMP is you have more opportunities for cross-over. You can write custom controls that use both sets of libraries. I could write a Sitefinity (or whatever) control that used BBNC DLLs and functionality. Kind of cool. I haven’t gone too far down this road (just finished my first, very simple, custom control), but I suspect you could build out BBNC functionality outside of their CMS rendering engine, just using it for its libraries. A lot of work, but an interesting idea.

If you have specific questions, feel free to shoot me a PM or email. And thanks for reminding me to post another installment…

[Victor]

Let me add some points to this list, if you don't mind

- Content Migration has to be done page by page
- Uploading pictures to the image library (v5.1 and previous - you have to upload each image individually, v5.5 - max 5 images uploaded at one time)
- Blackbaud will only style (Cascading Style Sheet) parts you have purchased in your SOW, other parts need to be styled on your own
- Customizations are only supported for the current version of your BBNC. If you upgrade in the future, your Customizations warranty expires (basically), meaning you have to pay up to get it to work in the new version.
- Content Authors / Site Admin's of BBNC site MUST use Firefox or Internet Explorer 6.0 or higher (no Safari or Opera browsers)
- Menu 1.0 styles don't import into Menu 2.0 (this is something a number of others on this board have raised concerns about and Blackbaud has done nothing (so far) about this). There is a thread on this topic that you can read up on if you like.

There's tons more I can type, both good and bad. There are some very positive things.

But if you are about to purchase BBNC, make sure you do your home work. ASK QUESTIONS on this board, ask questions to other similiar BBNC clients, don't just ask the sales person. The sales person is just that, a Sales Rep, they are out to make some money.

If your question is "Can we alter the desin of our site in the future?"
Sales Rep's answer "Oh ya, totally. You can have a completely new design every few days if you like."

The true answer should be "Oh ya, totally. You can have a completely new design every few days if you like, but in order to have a new design, you will need to have Photoshop experience, also know how to manipulate Cascading Style Sheets (for those of you that don't know, its a programming language that formats a site.)"

Alright I'll write the positives some other day.

[mathew]

Hi,
Dragging up an old thread..
Were you able to implement the targeting and security feature of BBNC CMS with Sitefinity? I don't like the BBNC CMS but we have pages that we like to restrict to roles for targetting content and privacy.

Cheers.

[mturkington]

Wow, I didn't mean to abandon this thread, but I guess things got a little busy after launch! And now we're working on an overhaul/re-launch. It never ends.

@Mathew: You know, I haven't been able to take that on. We don't use targeting heavily in BBNC, so it hasn't been a priority for us. I know I started working on it, but other things took over priority.

If you happen to be a .NET guru, it shouldn't be too hard. You have to write a .NET membership provider, which is highly documented. You just need to implement the various interfaces it needs, targeting the BBNC database as your backend data source. The biggest hurdle I ran into was finding out what hash BB uses for the passwords.

Alternatively, I think you can do something with Kerberos and BBNC's "single sign on" feature, but I've only seen about a paragraph on SSO anywhere in the documentation, and it doesn't exactly explain how it works.

But with either of those solutions, you'd be able to do what you're asking for, yeah. Since .NET is aware of both of those authentication sources, you can hook up any .NET compliant CMS to it and share a single directory.

If anyone from Blackbaud is still following this thread, that's (one of) a big suggestion: use more standard .NET stuff. Turn your authentication and authorization systems into the built-in .NET framework. You'll make extensibility much easier for us.

Let me know if you have questions. Sorry it's not a horribly helpful answer....

[Harriet]

I have a definite love/hate relationship with BBNC. We chose it because of the intregration with RE, knowing we were losing some of the "bells and whistles" associated with other on-line fundraising products.

I did have to educate myself on using style sheets - but found that was not a big deal. I also had to figure out how to manipulate/create new layouts and templates for new on-line pages with different content requirements, but after using then a while, and despite the design limitations, it has become a pretty easy task.

What drives me crazy about BBNC is mostly related to the 'part' called Fundraiser. It lacks so many basic functions and some areas are very poorly designed and cause frustration for our users who are trying to set up their personal/team fundraising pages. The two worst areas are importing an address book, and uploading images. Also, from the user perspective, the pages are not very flexible and limit their ability to add design feautures to their own page.

My other complaint is that you cannot export the list of registrants for a team event from the BBNC side. We can and do get this info from the RE side, but it is always somewhat behind the BBNC side since some registrations and donations will not appear on the RE records until processed through the plug-in.

However, on the positive side, I was informed by BB that great changes are being planned for the fundraising part. I would, of course, like to know what those changes are, and when they will be available. Steve McLaughlin - are you listening in? 8>)

[nisaac]

This is a great thread. I have a question for all of you - did any of you look to implement vmware? I have to make the decision whether to go that route.

Harriet, I agree with you whole completely about the BBNC team fundraising. We had the issues you discuss and more. Each year you have to create a new fund for each team fundraiser - we were running at least 8. RE and BBNC were always off in total numbers due to timing of synchronization. We added on Sphere FAF and it's been great. It's so interesting to see the differences offered in each product. We still use BBNC for all the wonderful things it does, but our Team fundraising is on Sphere, as well as, our e-store. The cost of running this hosted app is well worth the reduction in headaches for us and our constituency.

We are a small organization and currently run many databases on our main db server, including RE, FE, BBNC and TRE. We do have two separate web servers (we have BBNC and host another website for our patient services). It's difficult as it is to have the servers we need - PDC, Exchange, DB, Websites - then you go on to the intranet and other apps server. I'm have an rfp out to consultants to help me with our network rebuild. Most suggest VMWare.

[Augie001]

We are currently using VMware for all our BBNC servers, RE database and our test environment. It can be expensive (educational discount helps) but we made an initial investment 3 years ago and have not had to purchase any servers in that time frame, while adding 15 or so servers to our organization. The most useful tool for me is the ability to take a snapshot of the server before installing a patch and being able to revert to the pre patch server in a matter of minutes. EXAMPLE Raisers edge patch 4 did not agree with our trend micro antivirus.

VMware has worked for us
___________________
Augie Venegas
IT Administrator
Belen Jesuit Prep
www.belenjesuit.org

[nisaac]

Thank you. This is great info