es wäre ja zu schön gewesen – auf high level sind all die ganzen sharepoint 2010 features ja wirklich sehr, sehr fein. nur der hund steckt halt im detail, wie man so schön sagt.

da wollte ich wissen, wie eigentlich ein managed metadata field über infopath aussieht. die antwort ist recht einfach: gibts nicht:

schade aber auch

it has been very silent on my blog for the last months, so it’s really time for a new post, isn’t it?

so let’s talk about publishing sharepoint to internet – no big deal, right? there are several documentations, which do provide a step by step guide, like this one for isa 2004 – so this should be no problem at all. normally, you’ll want to have the same URL for your webapps, no matter if you call them inside your company network or from the internet. by doing so, all links are working, connected content to outlook is still syncing, etc, no matter where you are – the only need is to have internet access.
so in this case your answer is split-dns?

i think it’s not, at least in the most cases.

just to be sure – what is split dns? it’s nothing more or less to have the same dns zone, let’s say “company.com”, two times: one internal, and one external. so that means that you may define a different ip behind your A-records – a lookup then from external will resolve the external ip, a lookup inside your company lan will resolve the internal ip. this is fine, but you’ll have to maintain each of your records twice, because you cannot use forwarders – if a record (“moss.company.com”) is just existing on the external dns, a lookup from your company lan will just return *** dns.company.com can’t find moss.company.com: Non-existent domain

so what is the alternative?

it’s really very simple:
1) your external dns zone stays as it is
2) on your internal dns server:
a) create a new primary zone, where the name equals the fqdn (like “moss.company.com”).
b) create a new A-record in this zone, but enter just the internal ip (like “192.168.0.100″) and leave name blank.
c) finished!

due to this configuration an internal lookup of “moss.company.com” is answered by the internal dns server and resolves to 192.168.0.100 – but a lookup of “www.company.com” is still forwarded to your external dns server, which is exactly what we want – with this approach you’ll not have to maintain ALL entries twice – only those which should resolve to different ip’s need to be created also on your internal dns server (steps 2a – 2c).

the following picture shows this in detail again:

please keep in mind, that this has nothing to with sharepoint – it works for everything else like ocs, normal websites, owa, etc also!

dritter und letzter teil fuer kurt: kann man z.b. felder ausblenden? ja; und zwar so:

natuerlich brauchen wir dazu wieder den sharepoint designer (ja, man kann felder auch per javascript/css ausblenden, aber wozu?):

das newform.aspx oeffnen, und dann das originale webpart verstecken (loeschen ist nicht so gut: Error message when you click "New" to create a new item in a list or when you click an existing item in SharePoint Server 2007 or in Windows SharePoint Services 3.0: "Invalid page URL" or "An unexpected error has occurred"):

“hidden” markieren:

ein “custom list form” einfuegen:

in diesem fall fuer die liste “rechnungen” und fuer neue elemente:

jetzt haben wir alle moeglichkeiten – z.b. eben ein feld entfernen:

kontrolle: ja, es funktioniert (wobei dieses beispiel natuerlich nicht besonders sinnvoll ist.):

wenn man das vorherige beispiel hernimmt, so koennte man sich ja wuenschen in einem view zu jedem kunden die offenen rechnungen anzuzeigen – und ja, natuerlich geht dies:

im sharepoint designer oeffnen wir dazu die data sources:

und erstellen eine neue linked source:

die beiden listen hinzufuegen und next klicken:

in diesem fall ist “join” die richte wahl:

noch einen namen vergeben und dann “ok”

jetzt fuegen wir den data-view ein:

und markieren aus der liste “kunden” den kundennamen und fuegen diesen als “multiple item view” ein:

es werden nun also kundennamen angezeigt:

jetzt einen kunden markieren, das gewuenschte feld (die gewuenschten felder) aus der liste rechnungen markieren und als “joined subview” einfuegen:

die beziehung definieren:

das wars schon fast:

jetzt noch filtern:

und fertig (natuerlich koennte und sollte man es noch etwas huebscher gestalten.):

speziell fuer meinen freund kurt hier ein kleiner ausflug in den sharepoint designer; gestern haben wir darueber telefoniert, hier also nochmals im detail:

nehmen wir an, wir haben zwei listen:

eine mit allen kunden:

und eine andere mit allen rechnungen. diese liste verwendet einen normalen lookup auf die kundenliste.

so, du wolltest z.b. nach mehr als zwei feldern gruppieren und von einem datumsfeld nur das jahr anzeigen. here wo go:

man oeffnet nun also einfach die anzupassende view im sharepoint designer, und wandelt den view mittels “convert to xslt data view” um:

nun haben wir alle moeglichkeiten – und fuegen im ersten schritt eine neue column hinzu, in die wir das gewuenschte datumsfeld ziehen:

nachdem wir ja aber nur das jahr angezeigt haben moechten, muessen wir noch die formel anpassen; das geht entweder direkt im code, oder natuerlich auch ueber das kontextmenu:

hier die notwendige formel:

und siehe da, es funktioniert:

jetzt noch sortieren und gruppieren:

die gewuenschten felder hinzufuegen:

und fertig:

natuerlich geht noch weit mehr; ganz praktisch ist es z.b. auch, die breite der columns anzupassen.

problem: anwender erhalten links auf dokumente per mail, die auf einem wss/sharepoint abgelegt sind – es handelt sich um einen https link. klickt der anwender auf solch einen link, so öffnet sich nicht das dokument, sondern er erhält folgende fehlermeldung:

die lösung ist recht einfach: die option “verschlüsselte seiten nicht auf dem datenträger speichern” ist aktiviert – einfach deaktivieren, und schon wird es funktionieren…

das ist eine nicht so seltene frage, die man zum glück recht leicht beantworten kann:

1. perfmon öffnen
2. von jedem webfrontend aus “web service” den counter “current connections” hinzufügen

fertig. leichter kanns wirklich nicht sein

die files im 12er directory sollte man ja bekannterweise ohnehin nicht anpassen, trotzdem wird eine design-anpassung gerne direkt in den files application.master, default.master und natürlich in der core.css durchgeführt.

wollte eben ein bestehendes design in meine vm übernehmen, und zwar per drag&drop vom host in die vm direkt auf die entsprechende stelle im 12er directory. und danach war sharepoint sehr böse auf mich und antwortete nur noch mit http 403 meldungen.

des rätsels lösung: fehlende berechtigungen auf den 3 genannten files; vererbung wieder aktivieren, iisreset und schon funktioniert es zum glück wieder…

vor allem bei großen installationen kann man die regional settings natürlich nich allen recht machen, daher sind diese durchaus mal für den einen oder anderen unpassend – ich fang z.b. in datumsfeldern in dem format MM/DD/YYYY oder eine wochenstart sonntag nicht so viel an. zum glück kann sich dies jeder selbst einstellen; dazu die persönlichen settings öffnen:

dort dann auf “my regional settings” klicken

und die gewünschten einstellungen vornehmen

speichern, fertig! schöner wäre natürlich, wenn die ie settings übernommen werden würden, aber man kann nicht alles haben

erst vor kurzem hatte ich ein wenig über die versionierung geschrieben – ok, es war heute – (btw: mehr unterschiede zwischen einem dms und einem fileshare habe ich hier in 5 teilen zusammengeschrieben: 1, 2, 3, 4, 5); und wie es halt nun mal so ist, gibt es auch details, die nicht so perfekt sind – wie z.b. die minor versions…

wichtig ist, dass man folgendes im hinterkopf behält:

- man kann die anzahl der major versions festlegen

- man kann die anzahl der major version festlegen, die minor versions haben

- man kann aber nicht die maximale anzahl der minor versions einer major version festlegen!

man erwartet nur bei der zweiten option die anzahl der minor versions festzulegen, tatsächlich ist dem aber eben nicht so:

Was passiert also, wenn man wie im Beispiel oben die einstellung 5/3 wählt? angenommen von einem dokument gibt es folgende versionen:

6.0 – 6.1

5.0 – 5.1 – 5.2

4.0 – 4.1

3.0 – 3.1 – 3.2 – 3.3

2.0

1.0

und man published eine neue major version, dann erhält man folgendes:

7.0

6.0 – 6.1

5.0 – 5.1 – 5.2

4.0 – 4.1

3.0 – 3.1 -3.2 – 3.3

2.0

warum? nun, die version 1.0 wurde gelöscht, weil es die 6 major version ist, jedoch ja nur 5 aufgehoben werden. wenn man nun die nächste minor version, also 7.1, erstellt so werden 3.1 – 3.3 ebenfalls gelöscht; weil ja nur von 3 major die minor versions aufbehoben werden; also eigentlich ziemlich einfach, oder?