Minor update „Sign In As A Different User“ für OWA und HTML Redirection

Ich hatte heute auf unserem Bootcamp eine Anfrage von einem unserer Consultants bezüglich meines Projektes zum Wechseln von Benutzern auf dem IIS bekommen. Ich hatte das vor kurzem in einem Post gebloggt. Es ging um eine Konfiguration im Bereich Publishing TMG und genauer um Forms Authentication vs. Integrated Authentication. Wir haben kurz die Anwendung im Lab OWA erfolgreich getestet. Je nachdem wie der Kunde sich entscheidet gehen wir damit auch Live.

Bei der Konfiguration sind uns allerdings ein paar Dinge aufgefallen:

• Die Konfiguration im OWA Ordner war nicht erfolgreich. Alle Aufrufe für den Handler wurden ignoriert und es wurde OWA angezeigt.
• Die Lösung war einfach auf dem Web einen neuen Ordner im Root anzulegen und dort eine eigen Application für den Handler zu konfigurieren. Bei einem ersten Test ist allerdings aufgefallen, dass die Authentifizierung erst mal nicht wollte. Problem könnte hier Kerberos sein, da der normale App Pool ein anderen Account verwendet. WIr haben kurzerhand einfach den OWA App Pool verwendet und schon funktionierte die Lösung.
• Nach der erfolgreichen Ummeldung landet man aber per Default im Root des aktuellen Folders, was für die OWA User jetzt keine Option ist, da hier nichts liegt 🙂 Mein Kollege hat das ganze per HTML Meta Refresh gelöst und ich hab das dann gleich integriert, da ich so ohne Code Änderung auskommen.

Bis heute habe ich tatsächlich schon 26 Downloads und immerhin 286 page visits 🙂

Ciao Marco

ASP.NET 4.5, SQLMembership und (keine) Roles

Wir sind aktuell auf Bootcamp und ich habe Claims und alles drum herum zum Thema. Natürlich ist auch die Migration aus „alten“ Systemen ein Punkt auf der Agenda. Ich brauche also ein altes System… Also habe ich schnell eine ASP.NET 4.5 WebForms Site angelegt und konnte auch schnell die Logins aus dem SQL Membership Provider zum Fliegen bekommen. Allerdings konnte ich keine Seiten vor Zugriff über eine spezielle Role schützen. Hier meine Web.Config:

<location path=„Admin.aspx„>

<system.web>

<authorization>

<allow roles=„Admins„/>

<deny users=„*„/>

</authorization>

</system.web>

</location>

 

Bei einem Test hattet die Konfiguration aber kein Erfolg. Mein Admin User durfte die Admin.aspx einfach nicht sehen. Eine kurze Recherche hat gezeigt, dass ich den Role Provider der zwar vorkonfiguriert war noch enablen mußte.

Vorher:

<roleManager defaultProvider=„DefaultRoleProvider„>

<providers>

<add name=„DefaultRoleProvider„ type=„System.Web.Providers.DefaultRoleProvider, System.Web.Providers, Version=1.0.0.0, ulture=neutral, PublicKeyToken=31bf3856ad364e35„ connectionStringName=„DefaultConnection„ applicationName=„/„ />

</providers>

</roleManager>

 

Nachher:

<roleManager defaultProvider=„DefaultRoleProvider„ enabled=„true„>

<providers>

<add name=„DefaultRoleProvider„ type=„System.Web.Providers.DefaultRoleProvider, System.Web.Providers, Version=1.0.0.0, ulture=neutral, PublicKeyToken=31bf3856ad364e35„ connectionStringName=„DefaultConnection„ applicationName=„/„ />

</providers>

</roleManager>

 

Anschließen konnte ich mit dem Admin User die entsprechende Seite aufrufen 🙂

Ciao Marco

SharePoint 2010 Diagnostics Log Files werden nicht komprimiert

Ich hatte vor einiger Zeit bei einem Kunden das Problem, dass die Diagnostic Logs von Microsoft SharePoint 2010 nicht automatisch komprimieren ließen. SharePoint kümmert sich ja selber um die Verwaltung des Speicherplatzes. Eines der neuen Features ist, dass auf die Files in dem LOGS Ordner automatisch die NTFS Kompression aktiviert wird.

Der Kunde betreibt mehrere Farmen (Production, Staging, Testing und Dev), um den ganzen Lifecyle des Deployments korrekt abzudecken. Bis auf die Produktion laufen alle Farmen als Guest in geshared virtuellen Umgebungen. Die Produktion hat eigene Virtualisierungshosts und wurde extra für SharePoint neu aufgebaut. Ich konfiguriere (abweichend vom Standard) das Verzeichnis der LOGS nicht in den 14er Hive sondern auf „D:SP2010-DiagLogs“. Auf einigen der Maschinen im Staging ist mir dann aufgefallen, dass der Ordner für das SharePoint Diagnostics Logging keine NTFS Kompression verwendet. Im ersten Moment dachte ich, dass hier hat einer der Kollegen was „konfiguriert“ und ich wollte es manuell gerade ziehen. Ich stellte allerdings fest, dass die Option für die Kompression des Dateisystems nicht existiert.

Eine kurze Recherche brachte zum Thema SharePoint Diagnostic Logs wenig, um nicht zu sagen gar nichts. Die Suche wurde nun erweitert auf OS-Ebene, da die Funktion der „File Compression“ nicht durch SharePoint bereitgestellt wird. Es stellte sich dann langsam heraus, dass die Funktion nur für Platten bereitsteht, die mit einer Cluster-Größe von 4kb formatiert wurden. Hier ein Auszug von Microsoft Support:

The minimum default cluster size for NTFS under Windows NT 4.0 and later is 4 kilobytes (KB) because NTFS file compression is not possible on drives with a larger cluster size.
http://support.microsoft.com/kb/140365/en-us

Und es war tatsächlich so, dass in einigen der D: Drives der Guest im Development eine „falsche“ Cluster-Size hatten.

Ciao Marco

Sign In As A Different User – Benutzer wechseln für IIS basierte Sites

Meine Kollege Karten Kleinschmidt und ich haben beim Kunden ein interessante kleine Aufgabe bekommen, in der es darum ging, den verwendeten Benutzer (Domainen Benutzer) an einer bestehenden Webseite zu wechseln.

In einem Unternehmensnetzwerk mit integrierter Anmeldung an der Domain muss der User im Normalfall keine weiteren Anmeldeinformationen eingeben, um auf Websites zuzugreifen. Anwendungen wie SharePoint, CRM und viele Eigenentwicklungen nutzen diese Funktion natürlich für Authentifizierung und Autorisierung aus. Es kommt aber immer mal wieder vor, dass der aktuelle Benutzer nicht der „richtige“ Benutzer für die aktuelle Aufgabe ist. In vielen Unternehmen haben Benutzer neben dem eigenen Account einen administrativen Benutzer (gkms und gkadm_ms). Ist man am PC mit dem normalen Account angemeldet und möchte nun den administrativen Account verwenden, dann muss man den ganzen Brower mit anderen Credentials starten, sich am PC ummelden oder per Terminal Services auf einem anderen Rechner anmelden. Anwendungen wie SharePoint bieten solche Funktionen Out-Of-The-Box bereits an. Für Anwendungen, welche das nicht können, ist es für den normalen Mitarbeiter im Unternehmen kein leichtes Unterfangen, diese Aufgabe zu lösen.

Karsten (und damit irgendwann auch ich) hat nun die Aufgabe, für eine Website im Lync Umfeld so eine Funktion anzubieten. Eine kurze Recherche (Bing | Google) hat gezeigt, dass Roel van Lisdonk in seinem Blogpost ASP .NET – C# – How to “Sign in as Different User” like in Microsoft SharePoint with Windows Authentication genau das beschreibt. Seine Lösung ist allerdings Page-basierend und ich wollte was allgemeineres. Ich habe dann einfach seine Code als Basis genommen, ein HTTPModule erstellt und das Ergebnis dann auf Codeplex veröffentlicht. Da nicht so viel Eigenleistung drin steckt, war es schnell klar, dass es nur „fair“ ist es weiter zu teilen. Hier ist also das erste Glück & Kanja Codeplex Projekt.

http://signinas.codeplex.com – Glück & Kanja Consulting AG – Sign In As A Different User

Das Projekt steckt sicher noch in den Kinderschuhen und kann deutlich erweitert werden, aber dafür gibt es ja Codeplex 🙂

Ich hatte übrigens viel „Spaß“ mit Codeplex, aber das ist ne andere Geschichte und die Schuld von TFS 😉

Windows Phone 7 test

Coole Sache

Posted from WordPress for Windows Phone

SharePoint Blob Cache Corrupt

In einer der SharePoint 2007 Farmen, die ich betreue, nutzen wir die Blobcache Funktion, um Video’s, Flash und Bilder zu cachen. Wir haben zwei Web Front End Server (WFE) und die Funktion leistet eigentlich gute Dienste. Es kommt allerdings immer mal wieder vor, dass Bilder (das Verhältnis ist viel höher zum restlichen Content im Cache) nicht mehr angezeigt werden und es ein ASP.NET Error gibt. Genau es gibt folgendes Fehler:

Server Error in '/' Application. 
-------------------------------------------------------------------------------- 

Cannot complete this action. 

Please try again. 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.Runtime.InteropServices.COMException: Cannot complete this action. 

Please try again. 

Source Error: 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.  

Stack Trace: 

[COMException (0x80004005): Cannot complete this action. 

Please try again.] 
   Microsoft.SharePoint.Library.SPRequestInternalClass.GetAclForScope(String bstrWebUrl, Guid guidScopeId, Object& pvarAcl, UInt64& lAnonymousMask) +0 
   Microsoft.SharePoint.Library.SPRequest.GetAclForScope(String bstrWebUrl, Guid guidScopeId, Object& pvarAcl, UInt64& lAnonymousMask) +238 

[SPException: Cannot complete this action. 

Please try again.] 
   Microsoft.SharePoint.Library.SPRequest.GetAclForScope(String bstrWebUrl, Guid guidScopeId, Object& pvarAcl, UInt64& lAnonymousMask) +349 
   Microsoft.SharePoint.SPReusableAcl..ctor(SPRequest request, String webUrl, Guid scopeId) +149 
   Microsoft.SharePoint.SPSite.GetReusableAclForScope(Guid scopeId) +133 
   Microsoft.SharePoint.Publishing.<>c__DisplayClass3.<EnsureAuthenticatedRights>b__0() +1296 
   Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state) +73 
   Microsoft.SharePoint.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2() +592 
   Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode) +319 
   Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param) +571 
   Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode) +135 
   Microsoft.SharePoint.Publishing.BlobCache.EnsureAuthenticatedRights(Guid siteID, Guid scopeID) +1020 
   Microsoft.SharePoint.Publishing.BlobCache.RewriteUrl(Object sender, EventArgs e) +2949 
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80 
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +171 

-------------------------------------------------------------------------------- 
Version Information: Microsoft .NET Framework Version:2.0.50727.3603; ASP.NET Version:2.0.50727.3082

Die Lösung in diesem Fall ist das Resetten des Caches für diese SiteColletion. Über die SiteSettings kommt man zu den “Object Cache Settings” und hier kann man die drei Checkboxen zum Zurücksetzen des Caches setzen:

Ich hoffe es hilft dem einen oder anderen, der noch in Sharepoint 2007 feststeckt 😉

Ciao Marco

Call 2 Action: ASP.NET Security Update Now Available

Eigentlich nicht mein Dinge auf irgendwelche Blogposts hinzuweisen, aber denke hier ist mal eine Ausnahme angesagt. Es geht um eine Lücke in ASP.NET, die seit einigen Tagen die Runde macht. Hier das Security Bulitin von MS:
http://www.microsoft.com/technet/security/bulletin/ms10-sep.mspx

ScottGu beschreibt sehr schön, was zu tun ist und welche Auswirkungen es hat, wenn man das ASP.NET Security Update anwendet.
http://weblogs.asp.net/scottgu/archive/2010/09/28/asp-net-security-update-now-available.aspx

Betroffen ist auch SharePoint (2007/2010) und somit sollten alle Admins loslegen.

Unsere Sharepoint 2010 Installation hat leider eine Reboot benötigt. Auch wenn ScottGu sagt, dass es eigentlich keinen braucht… Schade.

Ciao Marco

Zune Software 4.2 ist da

Jetzt fehlt nur noch das passende Telefon. Windows Phone 7 ich komme.

Ciao Marco

Umzug – Phase Zwei

Heute bin ich wieder ein Schritt weiter. Die fehlenden Bilder aus meinem GraffitiCMS wurden dank S3 und dem Search & Replace Plugin gerade gezogen.

Offen sind jetzt noch ein paar URL’s, die ins Leere laufen, aber mal sehen, ob mir da noch was einfällt 🙂

Ciao Marco

Website ist umgezogen

Lange ist es her und dann so was langweiliges. Der Blog läuft jetzt auf WordPress. Mein vServer wird in den nächsten Tagen geplättet. Ich hoffe auf einen reibungslosen Umzug. Dank der eingesetzten Tools sollte keiner was merken. Das Theme update ich irgendwann nochmal, allerdings halte ich nicht viel davon Arbeit in die Oberfläche zu stecken. Der wahre Blick auf ein Blog geht sowieso durch Google Reader. Danke Feedburner muss NIEMAND sein RSS Reader anfassen.

Drückt mir die Daumen, dann gibt es hier bald auch wieder echten Content.

Ciao Marco