New-SPConfigurationDatabase – system error 5 (Access is denied.)

This not something very fancy and the solution is actually very clear and something I should have understood right from the error message. But because it took me a while to figure it out and googling with error message didn’t give that much help, maybe this helps someone else also.

I was installing SharePoint 2010 in very typical three tiers environment. SQL Server was installed as it should be based on best practice recommendations. This means that log and data files were also separated to different drivers. SharePoint was also meant to be installed based on least privilege practices. I was using power shell script to make the SharePoint installation but the same error is given to you with wizard also.

So on the stage where Configuration database is created I get the following error

New-SPConfigurationDatabase : CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file ‘R:\Log\Config_log.ldf’. CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

And now what?

I know that my setup account has all the necessary privileges to SQL Server. First I thought that my setup account should have access privileges to Log folder (where all the database log files are created) and I tried that with no help. After some googling, wondering and discussion with my colleague I figured it out.

The SQL server instance is driven with service account. Even though I’m using a setup account to operate in SQL server the actual creation of database is done with service account. I checked the SQL Server Services log on account with Sql Server Configuration Manager and gave this account read/write access to Log –folder.

And that solved the problem and the installation process was over quite quickly.


SharePoint 2013 and Search-Driven Content

For the last year I have done a lot of concept and architecture design together with development in cases where SharePoint is used as organization internal communication, news, announcement and general information channel. Basically I mean traditional Intranet with news pages, announcements lists, blogs, HR content sites, department sites etc. For this reason I have spent my time looking the new SharePoint 2013 Preview (SP2013 on this point of view. There is so much to look into and learn that you better start from something you are familiar with. I have tried to find out what there is new for my customers that are using SharePoint with Publishing Portal features inside their company. So few upcoming posts, including this one, will include my thoughts and findings on this point of view.

Here is how the Publishing Portal looks in right after creation

Search-Driven Content web parts

First big thing that you should notice are new web parts related to search. They are called Search-Driven Content web parts. When showing something like announcements in page on SharePoint 2010 (SP2010) you basically had four options 1. List View web part 2. Content Query web part 3. Search Result web part 4. Custom web part. In all of these there are pros and cons and you can still use them.

But SP2013 introduced a whole set of new search-driven web part. It seems that Microsoft really wants us to use search index when fetching and publishing content on the site. And I don’t claim them from doing so. Search index is very efficient and safe way to do it.

Content query web part is create but there is a possibility that your site is slowing down if you get content from a large site. That is why search is a create option. Only problem in SP2010 is that Search Result web part isn’t very useful way to do things and you are able to use List View web part only on that site where the list is located (without some SharePoint Designer hacks). So I have to say that in quite many occasion we went to road of making custom web part for some needed components on the site. Now I think that we can change this thinking at least in quite many occasion.

Available web parts

  1. Content Search – Web Part will allow you to show items that are results of a search query you specify.
  2. Articles – Web Part will show any items that are derived from the Article Page content type.
  3. Catalog – Item Reuse Web Part to reuse or republish the content of an item from a catalog.
  4. Items from a Catalog – Web Part will show items from a catalog configured for this site.
  5. Items Matching a Tag – Web Part will show items that are tagged with a term.
  6. Pictures – Web Part will show any items that are derived from the Picture or Image content type.
  7. Popular Items – Web Part will show items that have been recently viewed by many users.
  8. Recently Changed Items – Web Part will show items that have been modified recently.
  9. Recommended Items – Web Part will show content recommendations based on usage patterns for the current page.
  10. Videos – Web Part will show any items that are derived from the Video content type.
  11. Web Pages – Web Part will show any items that are derived from the Page content type.
  12. Wiki Pages – Web Part will show any items that are derived from the Wiki Page content type.

All of these web parts can fetch, except Recommended Items and Catalog-Item Reuse that have special features, data from current site, current site collection, specified URL or whole index (=Don’t restrict results by location). You are able to control this with query builder in web part properties. I will tell you more about this later. This really means that you fetch and show items from almost every possible location. This is why using index in these web parts is so powerful.

Use cases that customers wants

As you can see there are a lot of good and useful web parts for your intranet site. Something like popular items, articles (news pages) or recently changed items are something that customers ask almost every time. I can really see that these will be used a lot when people learn how to use them and can recommend those to customers. You can also create extra value in you intranet with these web parts because you can focus content more closely to users in different places regardless where the content is actually created and saved.

You can for example show department related news or blog post in department community site with Items Matching a Tag web part. Only thing you have to do is create necessary managed metadata and use those when publishing different kind of content. I really think that if organizations start to use these web parts effectively we will see good and really useful intranets in the feature. Laura Rogers has written a good overall look to Content Search web part that you should take a look at: SharePoint 2013 Web Part: Content Search

Something like popular items, articles (news pages) or recently changed items are something that customers ask almost every time.

And just as a site note Content Query Web Part has also this new Query builder that I like already. Catalog mentioned on some web parts, by the way, is a new thing is SP2013. Catalogs are used in cross-site collection publishing. MVP Liam Cleary gives a nice example of using catalogs and search-drive web parts here: SharePoint 2013 – Cross Site Collection Publishing Part 1. More information from cross-site collection publishing can be found here: What’s new in web content management for SharePoint 2013 Preview publishing sites.

Plan the metadata and search!

Of course using these web parts means that you have to plan, maintain and implement your search and metadata model well. Otherwise you can’t take a really advantages from these web part. I have notice that even though many people sees that metadata and terms are important it’s not that easy to implement and adapt them to organization. Now is the real time you start to think about these things and start to discuss about metadata. Remember that that metadata is not about technical issues, it’s about real life artefacts and content. You can create metadata model without SharePoint and IT department J. We can make many nice technical solutions but if people don’t tell what kind of items they save to SharePoint we can’t take full advantages from the possibilities.

Continuous crawl

Other important thing to release here is that index is not real time. You have to tell this to your customers and make clear that they understand this limitation. Corey Roth has written a create post about search in new SP2013: Search is Everywhere! What you need to know about Search in SharePoint 2013 Preview. One basic thing is to master and schedule your content sources. SP2013 introduced a new thing called continuous crawl.

Here is what Corey he says about continuous crawl:

“This crawls your content source continuously (every 15 minutes by default). However, there is some magic that occurs now and new items can appear in the index within seconds.”.

I think that in the environment that we are talking about you should definitely use this crawling option.

I wrote down a little more about continuous crawl and configuration about it in a separated post Using and Configuring Continuous Crawl.

So everything is perfect now?

Well as you can guess from the topic I think there are still things that could have done differently. One of mine top ranked wishes for the new SP was easier handling of xsl files in content query web part. This didn’t unfortunately come true. The same thing concerns also these search-driven web parts. Styling is done is xsl file. You still have to open/copy the xsl file, make the changes and save them back to styles library. Of course you can use SharePoint Designer or Visual Studio to make the changes. And if you want to link the web part to another style sheet than OOTB one you still need to take the road of SPD or Visual Studio solution. What I was expecting was xsl editor in web part level, or minimum of possibility to link you own custom xsl file like in List View Web Part. But this didn’t come, at least not in this preview version.

One of mine top ranked wishes for the new SP was easier handling of xsl files in content query web part. This didn’t unfortunately come true.

Other missing thing in these search-driven web parts is that you are not able to create personalized views or behavior to them. For example there is no possibility to filter the search results based on user profile value like department. You can only give the department value as static property. For sure you can use target audience and but multiple web part to the site but is always a maintenance hazel. Ok, to accomplish there should be some kind of scripting possibility on the query builder.

Luckily there is always my favorite framework solution MatchPoint that can handle these two issues. MatchPoint has web part called Composite Web Part. This web part can be connect to different data sources, you can modify the query with easy to use editor and you also have an editor to handle the styling. Composite also have a special expression framework that you can use to make dynamic queries during the load time. With this web part we have made solutions where we have fetched data from different sources based on user profile values and styled them with xsl. Here’s basic information about Composite web part but I will post more details of MatchPoint Composite web part little later: MatchPoint Composite Web Part

Using Search-Driven Web Parts – Example

I think that let’s stop this novel writing and let’s look something practical example. Here is on example of using search-driven web parts in communicational Intranet – SharePoint 2013 and Search-Driven Content – Articles Web Part.

SharePoint Application Configuration part 1 – Property Bag

Property bags are power full and good way to store properties and static details that is used in SharePoint. Earlier the most common way was to store for example some URL information in web-config. And still web.config is a good place to store information. Only administrators are able to modify web.config so the information is saved in quite save way. One disadvantage (a big one even) there is with web.config. If you have multi server farm you have to make web.config changes to every server so that everything would work.

However property bags are handles through code or xml file and application server is handling the information so that information is always reachable. You can store information in many different level and object like SPFarm, SPServer, SPWebApplication, SPContentDatabase, SPWeb, SPFolder, SPListItem, SPFile. “Each property bag allows you to store a collection of key/value pairs, each key is unique, and the value has to be a string. If you need more advanced capabilities, you could choose to store complex data in the string using serialization.[1]” Property bag are available both on server solutions and sandbox solutions (from site collection level and below). Even external application can use them if they connect to SharePoint environment through API.

Advantages to use property bags

· There are provided to you out of the box.

· They are saved straight to SharePoint databases.

· There is good and simple API to use them.


· No out of the box UI to modify them. But there is an good farm level solution found from Codeplex

How to use property bag?

But let’s have an example of how you can use property bag in our solutions. This example is light version from real life case. Our customer wanted to have web part that can be used in multiple sites and multiple times in a site. The request also was that they want to make multiple predefined style themes from which site administrators can choose from. This meant that on a site there could be multiple web parts but all of them have different style layout (font color etc.).

On this post I will leave the creating of visual web part with editor part out. But you can download the source code from the link below and there are a lot of examples found with Google of course.

Our web part fulfilled the requirements in a following way.

a) Make the web part based on visual web part and add custom style classes to every control on the page.

b) Themes can be made so that there will be necessary CSS styling done and user can change this style to a single web part.

c) Make editor part where users sees drop down box and styles (like Blue Theme, Red Theme) from where to choose from.

d) This list of styles should be centrally defined by administrators.

e) Theme list will be saved in property bag and administrator can update it with pbs2010 tool found from Codeplex.

First we need to create the actual property bag. On this demo we create the properties on site (or web) level.

1. Create an empty module to your visual studio solution.

2. Into element.xml file here is the xml definition we used to list the possible style themes. More information about property bag xml schema can be found here: Property Bag Schema.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="">
  <PropertyBag ParentType="Web">
    <Property Name="pbpost.messageboxstyling" Type="string" Value="Blue Theme, Red Theme" />

3. Save the element file and create a feature that will install the module to the site.

Getting the property bag information

As I told there is a editor part where we want to show list of possible styles in drop down list. The styles are saved to web property bag with a key pbpost.messageboxstyling. Teams are saved as comma separated string so we also have to decrypt them as single items.

Here is the create CreateChildControl function where we are creating the drop down list and start to fill that with the values from property bag.

protected override void CreateChildControls()
                //Create the Dropdown list
                SelectedNewCssClass = new DropDownList();
                //Add the item from property bag

                Label lblControl = new Label();
                lblControl.Text = "Box Custom CssClass";
                Controls.Add(new LiteralControl("<br/>"));
                Controls.Add(new LiteralControl("<br/>"));
            catch (Exception ex)
new SPDiagnosticsCategory("UsingPropertyBag", TraceSeverity.Unexpected,
EventSeverity.Error), TraceSeverity.Unexpected, ex.Message, ex.StackTrace);

And here is the actual function that reads the values from the bag and saves them as items to the drop down list.

private void addCSSStyles(DropDownList CssClass)

            if (SPContext.Current.Site.RootWeb.AllProperties.ContainsKey
                string[] cssValues = SPContext.Current.Site.RootWeb.AllProperties

                foreach (string value in cssValues)

So here was the short example and information about SharePoint property bags. You can find the complet Visual Studio 2010 solution from my SkyDrive (zip file names as


[1] Course 10232A: Designing and Developing Microsoft® SharePoint® Server 2010 Applications material

SharePoint Application Configuration – Application Configuration

imageLately I’ve been worked a lot with projects where we have tried to find a good way to give site collection owner or farm admins possibilities to maintain and even change the way how our custom SharePoint application (web part, controls etc.) work. The answer to this is by using configuration data. The main reason to use configuration is of course flexibility. User can change things, like connection strings, if they need to.

Other thing related to this is reusability. On organization things can and will change after the new applications is finished and taken to production. When we are talking about SharePoint this is an everyday situation because the whole platform is meant to change when you organization is changing. Having the things behind some configuration you can develop features that can be used in many different organizations and cases.

For development firms this means saving on development time and better contribution marking. I have always liked the idea to make features and solutions reusable. It takes a little bit more time to plan things but in many cases this consideration will mean better, cleaner and more user friendly solutions. But to make configuration really works it means that during the planning and development you have to find answer to the following questions.

1. What things should users to be able to change?

2. How to code this solution so that it can be changed and maintained with configurations?

3. Where to store the necessary configurations?

For question one and two there is no easy answer and it always depends on the case. Of course it’s always easy to forget question number two or actually all the questions. Just make the solutions that work on this case and don’t give users and possibility to change anything. Fast, but not very lasting on long term.

But for question number three there are few good possibilities that SharePoint offers.

· SharePoint Property Bag

· Web.config

· SharePoint List

· SharePoint Web Part

· Hierarchical Object Store

On this series I will go through them and try to give you a short idea of how they work, what are the pros and cons of them so that you can consider which of them could suite for your application. I will start with one of my favorites Property Bag. My first attend was that this post would include the actual how to part also, but I want to keep things short and the introduction part became longer that I was expected. I know how frustrating it is to read how to post where it too much scrolling before they get to the point.

So the first how to part will be published in a few days.

SharePoint Application Configuration part 1 – Property Bag

Vaatimusmäärittely – valtakunnallinen lippujärjestelmä

Sirukortti rahaa

Menet nettipalveluun tai rautatieaseman palvelupisteeseen. Pyydät lipun Tampereelta Somerolle. Voit maksaa koko matkan kerrallaan ja saat käteesi sekä lipun, joka kelpaa sekä junaan Tampereelta Saloon että bussiin välillä Salo Somero. Hintaa lipulle ei tule sen enempää kuin nytkään, mikäli ostaisit liput erikseen. Matka sujuu mukavasti ja liikennöitsijät saavat parin päivän sisällä tililleen heille kuuluvan osuuden matkoista.

Tämä on se tavoitetila avattuna user story muotoon, joka sisältyy uuden hallituksen tavoitteeseen valtakunnallisesta lippujärjestelmästä. Asia ei sinänsä ole uusi, sillä järjestelmää on pohdittu jo viime hallituksen aikana. Mutta nyt uuteen hallitusohjelmaan asiasta saatiin jo ihan virallinen kirjaus.

Otetaan käyttöön valtakunnallinen joukkoliikenteen lippujärjestelmä, jossa yhdellä matka-kortilla voi matkustaa kaikissa joukkoliikennevälineissä. Toteutetaan valtakunnallinen joukkoliikenteen aikataulu- ja reittipalvelu.

Varsinaisesti tuossa on kaksi erillistä sovelluskokonaisuutta ja asiaa, mutta ilman valtakunnallista joukkoliikenteen aikataulu- ja reittisovellusta tuskin saadaan mitään lippujärjestelmää aikaiseksi. Näin kahdella lauseella kirjoitettuna ja vain käyttäjän näkökulmasta ajateltua asia tuntuu hyvälle ja helpolle. Yhdestä luukusta koko matkalle tarkoitettu lippu palvelisi varmasti haja-asutusalueen ihmisiä ja kannustaisi joukkoliikenteen käyttöön. Perusperiaate on selkeä ja neljä vuotta pitkä aika.

Vai onko? Kaikki eivät tähän usko, kuten TS:n uutisessa “Valtakunnallisen matkalipun toteutuminen epäilyttää” kerrottaan.

Asiantuntijoiden mukaan kaikkeen joukkoliikenteeseen kelpaavan lipun toteutus on teknisesti ongelmallista. Lisäksi moni liikennöitsijä suhtautuu suunnitelmiin epäilevästi. Uudistus kustantaisi miljoonia euroja, ja osa summasta lankeaisi liikennöitsijöiden maksettavaksi.

Leikitellään hetki asian kanssa ja pohditaan eri toteutustapoja. Mielestäni selkein lähtökohta järjestelmälle on ottaa mallia vanhasta, mutta erittäin toimivasta, puolustusvoimien litterasta. Lätkäistään matkustajalle lippu käteen ja hän voi vain näyttää ko. lippua esimerkiksi bussissa tai junassa. Perille pääsee, kunhan vain löytää oikean kulkuvälineen. En tiedä miten litteralla matkustaessa matka korvataan liikennöitsijälle, mutta vaihtoehtona voisi olla liikennöitsijän ilmoitus matkasta valtiolle ja rahat kilisevät tilille.

Valtakunnallisen lippujärjestelmän haasteisiin kuuluu ehdottomasti maksujärjestelmän luominen. VR:llä tilanne on mielestäni hyvä, sillä konduktöörit voivat lukea useita erityyppisiä lippuja. Parhaana esimerkkinä voisi mainita viivakoodiluvun kännykästä. Mutta kaikissa valtakunnallisen lippujärjestelmän piiriin kuuluvissa liikennevälineissä tilanne ei ole näin hyvä. Seuraavassa on pohdittu muutamia eri vaihtoehtoja lippujärjestelmän toteuttamiseksi.

Valtakunnallinen littera

Nopeasti vastaavan tapahtumaketjun toteutus tuntuu yksinkertaiselta. Henkilö vain lataa yleislipun kännykkään tai tulostaa sen paperille ja homma pelaa. Yhtä koodia näyttämällä pääsee kaikkiin liikennevälineisiin. Tämä ratkaisu on ainakin nopea tapa järjestää asia. Haasteeksi tässä nousee kuitenkin rahastus. Miten kohdistaa matkan maksu juuri kyseiselle henkilölle?

  • Kysytään aina henkilön laskutustietoja
    • Vie liikaa aikaa. Asia pitäisi tehdä automaattisesti.
  • Koko matka on ostettava etukäteen ja järjestelmä jakaa laskun eri liikennöitsijöiden kesken.
    • Entä mahdolliset muutokset kesken matkan, miten hoidetaan esimerkiksi junatyypin vaihtuminen?
    • Ei ole tarkoituksen mukaista, että muutoksen kohdalla henkilön pitäisi löytää jostain palvelupiste, jossa muutoksen voisi tehdä.
    • Muutosta ei myöskään voida tehdä esimerkiksi liikkuvasta bussissa, sillä se veisi liikaa aikaa ja tarvittavat tietoliikenneyhteydet eivät välttämättä toimi.
  • Toki voisimme ajatella, että littera luetaan aina liikennevälineeseen noustessa vaikka viivakoodilukijalla. Tällöin matka voidaan ainakin jälkikäteen kohdistaa tiettyyn tilaukseen ja laskuttaa sitten tilaajalta.
  • Esiin nousee heti laitteiden kustannus. Toki hinta on alhaisempi kuin etäluettavien korttien lukulaitteen hankinta, mutta liikennevälineiden määrä on valtava. Emme puhu mistään pienestä hankinnasta.

Valtakunnallinen matkakortti

Yksi ehdotus on luoda valtakunnallinen matkakortti. Mitä tämä sitten käytännössä tarkoittaa? Ilmeisesti ainut mahdollinen vaihtoehto olisi ladata matkakorttiin etukäteen rahaa.

  • Eroaako tämä sitten nykytilanteesta kovinkaan paljon? Rehellisesti sanottuna ei. Ainoastaan nopeus puhuu matkakortin puolesta, muuten matkan voi maksaa vaikka käteisellä.
  • Nykyiset matkakortit ovat tekniikaltaan toki hyvin pitkälti samantyyppisiä (HF taajuudella toimia RFID kortteja), mutta lukulaitteiden toiminnassa on eroja. Lukulaitteiden sovellukset pitäisi siis harmonisoida, joka ei ole halpa asia toteuttaa.
  • Lukulaitteita ei myöskään ole kaikissa tarvittavissa liikennevälineissä, jolloin lukulaitteiden maksu lankeaa lähes varmasti matkustajille.
  • Kyseessä kun ei ole halpa investointi.
  • Tässä taloustilanteessa ei voida realistisesti ajatella, että valtio kustantaisi kaikkiin busseihin, juniin jne. lukulaitteita.


Ainakin monen kaupungin joukkoliikennekortti on nykyään etäluettava kortti, josta puhuttiin edellä. Toinen vaihtoehto olisi tietenkin ottaa mallia pankkikortista ja luoda järjestelmä sirukortin varaan. Ainakin useimmissa valtakunnallisen matkakorttijärjestelmän alle ajatellussa liikennevälineessä olisi sirukortin lukija valmiina.

Tässä vain nousee esille se fakta, että meillä on jo tällainen sirukortti. Sitä kutsutaan pankkikortiksi. Niin ja myös sirukortin kanssa eteen tulee lukijoiden erilaiset sovellukset. Päivitystä tarvitaan tässäkin ratkaisussa. Rahaa tuskin löytyy valtiolta tai yrityksiltä.

Valtio tukemaan kaikkea matkustamista

Tämä on kohtalaisen kommunistinen ajattelutapa, mutta yksi vaihtoehto muiden joukossa on harmonisoida matkojen hinnat. Harmonisoinnilla tarkoitan sitä, että sovitaan valtakunnallisesti eri liikennevälineiden hinnat samalle tasolle. Unohdetaan kilpailu ja tuetaan liikkumista valtion rahoista.

  • Sovitaan tietyn pituisille matkoille yhteiset hinnat liikennevälineestä riippumatta. Valtio tukee eri liikennevälineiden matkoja, jotta sama hinta on mahdollinen.
  • Matkustajat ostavat eri pituisia matkoja etukäteen netistä ja esimerkiksi tulostavat ne paperille. Koska hinnat ovat samat kaikilla liikennevälineillä.
  • Liikenne välineessä sitten leimataan matka käytetyksi. Liikennöitsijät raportoivat montako matkaa on käytetty.
  • Rahat ohjataan yhteen ja samaan keskusorganisaatioon, josta niitä tilitetään liikennöintiä tarjoaville yhtiöille matkustajamäärien mukaan.

Heitin tämän vaihtoehdon vain niin sanotusti ilmaan. Itse en tällaista suostuisi rahoittamaan verovaroin, mutta tarkoituksenani olikin pohtia vain eri vaihtoehtoja.

Yhdistelmäkortti – rajapinnat, standardit ja suositukset

Loppujen lopuksi lukulaitteiden ja maksujärjestelmien hankinnassa ja käyttöönotossa on kyse järjestelmien yhteensovittamisesta. Kenties ainut tapa toteuttaa valtakunnallinen lippujärjestelmä lienee yhdistelmäkortin luominen. Tämä tarkoittaa sitä, että luodaan kortti, jota voidaan lukea RFID:llä, viivakoodilla ja sirulukijalla.

Luodaan lukemiseen ja tiedäon välittämiseen avoimet standardit ja rajapinnat. Annetaan muutokseen tarpeeksi aikaa ja tehdään standardin mukaisista laitteista tulevaisuudessa välttämättömiä. Näin annetaan eri laitteiden valmistajille mahdollisuus rakentaa ja päivittää laitteensa tukemaan valtakunnallista järjestelmää.

Tällöin kenties pääsisimme tilanteeseen, jossa eri liikennöitsijöiden rahastusjärjestelmät ryhtyvät tukemaan tätä valtakunnallista järjestelmää pidemmän ajan kuluessa. Tämän jälkeen yhtenäisen rahastusjärjestelmän rakentaminen olisi helpompaa ja matkustajan rahastaminen kävisi helposti tilanteesta ja matkustusvälineestä riippumatta.

Kyseessä ei missään tapauksessa ole yhden hallituskauden aikana tehtävä asia. Kuntien ja valtion omistamien liikennöintiyritysten kohdalla tätä yhtenäistä järjestelmää tukevien laitteiden hankinta on vielä helposti tehtävissä. Siitä tehdään vaatimus kilpailutusvaiheessa. Mutta yksityisten yritysten kohdalla tilanne voi olla vaikeampi. Kenties asian voisi hoitaa jonkin (vero)porkkanan kautta. Toki pakottamallakin asian voisi hoitaa, mutta tämä ei olisi kestävä ratkaisu.

Ei kenties vielä

Mitä enemmän pyörittää mielessään asiaan liittyviä puolia ja erikoistapauksia, niin sitä vaikeammaksi valtakunnallisen matkalipun kehittäminen tulee. Ajatus on kuitenkin mielestäni ihan tavoiteltava. On vain löydettävä ratkaisu, joka on halpa, nopea käyttää ja joka jollain tapaa helpottaa maksamista. En itse suostuisi ottamaan käyttöön jotain uutta korttia tai tulostetta, mikäli pienemmälä vaivalla voin maksaa matkani suoraan käteisellä tai pankkikortilla.

Joku voisi jopa ajatella, että onko valtakunnalliselle lipulle edes käyttöä. Pidemmillä matkoilla en ole aivan vakuuttunut, mutta lähikuntien rajat ylittävillä ratkaisuilla on selkeästi tilausta. Toki meistä moni matkustaa jo nyt esimerkiksi junalla ja hyppää sitten paikallisbussiin, jossa joutuu maksamaan eri maksuvälineellä. Tällöin yksi kortti olisi perusteltua.

Itse olisin realistinen ja lähtisin kehittämään ensin valtakunnallista aikataulujärjestelmää. Jo siinä on tarpeeksi tekemistä neljäksi vuodeksi. Todellinen ratkaisu valtakunnalliseen  taitaa kuitenkin löytyä avoimien rajapintojen ja vapaaehtoisten laitepäivitysten kautta.

Tuleeko teille mieleen muita ratkaisuja tai ongelmia valtakunnallisen lippujärjestelmän toteuttamisessa?