maandelikse Argiewe: Maart 2009

Fun SharePoint SSO Feit van die Dag

1 Antwoord

I’ve been working with SharePoint SSO and learning as I go. One way in which this works is that you tell SharePoint about external applications. Users log into that application via some SharePoint function (bijv. iView web deel). The first time the user performs this action, it prompts them for the correct user id and password to use for that system. It’s setting up a mapping between your SharePoint credentials and your credentials for that backend system. Thereafter, Die gebruiker sal nie hul ID te tree wanneer hulle getref het dat die stelsel.

That part worked well for me. Egter, Dit lei tot die vraag, "Hoe die gebruiker verander wat 'n gebruiker id of wagwoord?” The user might have made a mistake, Of miskien het jy besig met 'n toets in 'n dev omgewing en die behoefte om vinnig te skakel tussen rekeninge.

Ek weet nie die antwoord op daardie, maar ek weet dat jy kan gaan in die Sentrale Administrasie en die bestuur van die gebruiker se geloofsbriewe:

Sentrale Administrasie -> Bedrywighede -> Bestuur Single Sign-On -> Bestuur rekening inligting vir 'n Enterprise Aansoek Definisie

Van daar, jy kan die eksterne program (bijv. SAP) and the account you want to delete. You can also change the mapping.

As jy weet hoe om die einde kliënte toelaat om direk verander hul geloofsbriewe, kindly post a comment 🙂

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin

Technorati Tags: , ,

Die Adventures Met iView Web Parts

Laat 'n antwoord

I needed to do some minimal proving today that iView web parts can work in my client’s environment. I’ve never worked with this slice of SharePoint before.

Microsoft het 'n baie hoë gehalte wit papier op hierdie onderwerp.

Die eerste hindernis het ek moes oorkom was - waar is die iView web deel? Vir een of ander rede, my first thought was that I’d have to download it from a site somewhere, perhaps SAP’s site. Ek moes 1/2 convinced myself that iView web parts might even cost extra. Natuurlik, they are included with MOSS (I think Enterprise; that’s what I’m using here in any event). I’ve seen the standard “add a web part” dialog box hundreds or more times and always glossed over it. No more!

The next obstacle is that I can’t read instructions.

I was using the web part and kept getting this annoying message:

No SAP servers are configured for this site. Contact your administrator to configure trusted SAP servers.

The white paper clearly says to edit a configuration file located at file “<Drive Letter:>\Program Files\Microsoft Office Servers\12.0\Config\TrustedSAPHosts.config”. The first dozen times I looked at that, all I saw was “Program Files…Config” and I went straight away to the 12 Hive. Once I finally slowed down to read it, I realized my mistake and it was easy to fix.

I continued on my merry way with SSO configuration. It’s not all at clear to me if that worked, but that’s another story for another day.

Bottom line:

1. iView web parts are included out of the box with SharePoint (probably Enterprise).

2. The magic configuration file, “TrustedSAPHosts.config”, does not live in the 12 Hive.

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin

MOSS User Profile as die Owerheid vir gebruiker Taalvoorkeur

4 antwoorde

Op my huidige projek, sommige van die gebruikers sal reis regoor die wêreld, en wanneer hulle kom op verskillende bestemmings, use whatever machine is handy at the time. Those guest machines will be running Windows and installed and configured for the local locale. (Ek het net besef dat die gaste masjiene nie kan het die reg om taal pakkette… sal waarskynlik nie, in werklikheid… Ek parkeer dat 'n mens vir nou).

SharePoint needs to provide a mechanism whereby the user can pick their preferred language and then have MOSS honor that language regardless of how the user accesses MOSS. In other words, disregard whatever the browser tells IIS/MOSS and instead look up that preferred language and use it.

Ons gaan twee benaderings te ondersoek:

  1. HTTP Handler: 'N persoonlike HTTP hanteerder geïnstalleer op IIS sal kyk op die gebruiker se mos profiel, die taal van voorkeur en dan skakel die HTTP-kop rond soos nodig voordat beheer te MOSS.
  2. Global.asax: Modify global.asax to do the same thing. We may modify something else, but the idea is that we find some place where we can insert our locale-switching logic.

Die ander kompliserende faktor is dat ons moet 60k gebruikers te ondersteun, oor 1,000 wat gelyktydig toegang tot spitslas word mos.

Die HTTP-hanteerder lyk redelik drastiese, but possibly the best place to put the code since it’s at the IIS level and all-knowing. It’s a good single point of work.

Ons leun na 'n Global.asax tipe benadering, hoofsaaklik omdat ons glo dat ons meer opsies vir die kas van data sal op daardie stadium.

Ek sal blog meer oor hierdie onderwerp as ek meer inligting.

As jy weet niks oor hierdie, please post a comment 🙂

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin

Vaslegging “mailto:” Statistieke

5 antwoorde

I’m on a project where we need to collect metrics around a function named "Share a Story." The idea is very simple — as jy op soek na 'n interessante artikel op die intranet en die wil om dit te deel met iemand, click a link labeled "Share this story" e-pos dit aan jou buddy.

Ons speel rond met 'n persoonlike vorm vir hierdie doel, maar op die ou end, gesonde verstand het die dag en ons gebruik net die bekende <a href = mailto:…> technique. (<'n href mailto:…> is 'n verbasend sterk bietjie van HTML; as 'n bonus, skakel bring my terug na my ou UNIX man bladsye dae; Dit was die dae!).

Hierdie tegniek bied 'n groot koppelvlak vir eindgebruikers, aangesien hulle hul bekende MS Outlook kliënt te gebruik (of enige e-pos kliënt dit geïnstalleer).

Dit maak dinge moeiliker op ons arme ontwikkelaar tipes omdat hulle kliënt * ook * wil 'n verslag in die toekoms wat toon hoe dikwels gebruikers deel stories en selfs watter stories is meestal gedeel uit te voer.

We whiteboarded a few potential solutions. My favorite is to carbon copy (CC) a SharePoint list. That way, the end user still gets the outlook client while we get to capture the event because we’ll get a copy of the email ourselves. There are some obvious drawbacks. The main problem is that the user could simply blank out or otherwise mangle the CC address. En, we need to manage that event library of emails. We have a scheduled job on the white board responsible for that cleanup.

As jy 'n slim benadering tot die oplossing van hierdie probleem, doen vertel.

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin