אחרי שיצרתי את הסביבה החדשה, והתקני את החווה, התחלתי להגדיר את ההגדרות הדרושות, ובין היתר, ניגשתי להגדיר ייבוא פרופילים.

בעמוד “User Profiles and Properties” קיבלתי הודעת שגיאה אדומה, לפני שעשיתי משהו. בהתחלה התעלמתי ממנה, במחשבה שזו אחת מאותן הודעות “עמוד זה אינו מוצפן”, אבל השגיאה מנעה ממני להגדיר את הייבוא, לכן הייתי חייב להתייחס אליה.

הודעת השגיאה היתה:

“An error has occurred while accessing the SQL Server database or the Office SharePoint Server Search service. If this is the first time you have seen this message, try again later. If this problem persists, contact your administrator.”

(צילום מסך של השגיאה)

חיטטתי ברחבי המערכת מעט, בדקתי רמות הרשאה וכל דבר אחר שיכולתי לחשוב עליו. אבל ההודעה לא נעלמה, למרות שלמשתמש איתו עבדתי היו הרשאות מלאות ל- Database.

קראתי מה שיכולתי ומה שמצאתי לגבי הבעיה, אבל שום דבר לא עזר לפתור את הבעיה (או שלא מצאתי את המאמר המתאים )

אחרי זמן מה, החלטתי להפעיל Profiler על ה- database כדי לראות כדי לראות מי ניגש אליו בפועל. ראיתי שאין גישה ל- database כשאני פותח את העמוד הנ”ל, אבל כשאני משוטט בשרת, נעשית גישה באמצעות המשתמש המשמש את ה- SharePoint Web Services.

ואז נפל לי האסימון.

הלכתי לבדוק את השער (Port) שבו משתמשים ה- Web Services. כדי לעשות זאת, באופן פשוט, ניגשים ל- IIS Manager על השרת המארח את ה- Central Admin.

ראיתי שהשערים המשמשים את האפליקציה הם 56737 (http( ו- 56738 (https).

(ה- Web Services ב- IIS)

הוספתי חוק “Allow” חדש, לאיפשור מעבר מידע דרך השערים הנ”ל.

והנה, המסך נטול שגיאה.

ו

מזה זמן מה אני הולך ומכבה שריפות SharePoint קטנות.

רצה המקרה ובחודשים האחרונים אני נקרא אל לקוחות שונים, בכדי לסייע להם לפתור תקלות ומצוקות שונות בחוות ה- SharePoint שלהם.

אצל לקוח אחד מודל ההרשאות לא היה קיים. לקוחות התלוננו על חוסר גישה, אנשי אבטחת המידע התלננו על עודף גישה, ובסופו של יום המערכת לא עבדה כמצופה ומשתמשים לא קיבלו את השירות.

לקוח אחר הגיע לנפח מסד נתונים אסטרונומי, ומספר Sites אסטרונומי עוד יותר (אני מדבר בתחום של אלפי אתרים).

נשמע לכם מוכר?

אל תדאגו, אתם לא לבד. ברוב הארגונים שאני מגיע אליהם קיימת “מחלת SharePoint” אחת או יותר.

למה זה קורה?

כפלטפורמה, SharePoint נותן כלים ואפשרויות למשתמש הרגיל, לעשות דברים שעל אתר “רגיל” הוא לא היה יכול לעשות.

החל מיצירת תוכן מגוון והעלאת קבצים, ועד שינוי מראה הדף ואפילו יצירת תתי אתרים וספריות.

וכמו שהדוד בן אומר בספיידרמן “With great power, comes great responsibility” (ולמעשה מצטט את רוזוולט).

כאן נכנסת תוכנית קטנה בשם Governance Plan.

מה זה בעצם Governance Plan?

לפי וויקיפדיה, משמעות המילה Governance היא מפועל יווני שמשמעותו “ניווט”.

מכאן, ש- Governance Plan היא בעצם תוכנית ניווט, או בפועל, התווית דרך.

התווית דרך פעולה, לנושאים שונים הקשורים בניהול מערכת התוכן הארגונית שלנו, או מערכת שיתוף המידע שלנו.

הדבר החשוב ביותר בתוכנית מסוג זה, היא הגדרת החזון. או, לאן ברצונכם להגיע עם מערכת שיטוף הידע הארגונית שלכם. אפשר לעשות הכל, בסופו של יום, אבל השאלה היא האם אכן אנחנו צריכים הכל, או שעדיף להתרכז בדברים החשובים בשלב הראשון, ואחר כך לנסות להרחיב (והתשובה היא כמובן החלק השני).

חשוב לזכור, שסביר להניח שהתוכנית הכללית לא תתאים לכל אחד בארגון. וזה בסדר. אבל במקרה זה התוכנית היא לא בסיס לשינויים. קבעו איזשהו בסיס איתן, וצרו ואריציות שלו לפי הצרכים השונים, תוך שאתם שומרים על העקרון הבסיסי שהגדרתם, ומפצלים את היישום ליחידות קטנות יותר (למשל, ל- Site Collections).

קחו את השליטה לידיים. יישום Governance ב- SharePoint 2010

היכולת לפתח ולהתאים את SharePoint קיבלה קפיצה משמעותית בגרסת 2010 של המוצר.

החל מיכולות משופרות בתחום עריכת וניהול התוכן, דרך יכולות חברתיות שהוספו למוצר, ועד צריכת תוכן ממערכות הליבה, באמצעים מובנים ודו כיווניים.

נראה שהכח עלה בצורה משמעותית.

ובמקביל, גם היכולת לשלוט בכח הזה עלתה משמעותית, ואכן SharePoint 2010 כולל יכולות מורחבות ומשופרות בתחום ה- Governance.

ראשית, גרעיניות ההחלטות ירדה אל רמת האתר. ניתן להגדיר מכסות (Quotas) ברמת האתר הבודד, כך שניתן ליצור אתר אחד המאפשר קבצי מדיה ענקיים, ולצידו אתר לניהול מסמכים “רזים”.

ה- Health Analyzer שהוצג ב- SharePoint 2010 נותן כלים לקבלת מידע על היישום שלך.

ניתן להגדיר בצורה פשוט מי יכול להתקין SharePoint בארגון ומי לא. או לחילופין, לקבוע סמן ב- Active Directory, שידווח לכם על כלל ההתקנות של SharePoint בארגון.

בשבועות הקרובים אכתוב בנושאים אלו פוסטים נוספים, הכוללים הדרכות על יישום היכולות האלו בארגון.

Tech-Ed Israel 2010

אני הולך לדבר על נושאים אלו בהרחבה, ב- Tech-Ed הקרוב, שיערך באילת בסוף החודש.

בהרצאה שאעביר ביחד עם צביקי גולדברג, נספר על מקרים בהם נתקלנו בשטח, ביישומים אמיתיים, מחיי היומיום של ארגונים שונים, ונתאר כיצד ניתן היה להימנע מלהגיע לאותו המקום וכיצד SharePoint 2010 מסייע לכם להשיג את רמת השליטה הנדרשת, ויתרה מכך, כיצד באפשרותכם, היום, באמצעים פשוטים, להחזיר את השליטה לידיים.

ההרצאה מיועדת לכל מי שעוסק ב- SharePoint בחיי היומיום, אבל בעיקר לאנשי IT הנדרשים לכלים ויכולות בכדי להחזיר שליטה מסוימת במערכות ה- SharePoint שלהם.

אשמח לראותכם.

• (English version of this post)

לצערי אני לא יכול להוסיף קוד לפוסט, לכן אני ממליץ להוריד את הקוד ולקרוא אותו במקביל לקריאת הפוסט.

להורדת הקוד הבסיסי.

להורדת הקוד ליצירת דפים מרובים.

המטרה

יצירת דפים בקוד היא דרך נוחה ליצור דפים בצורה מהירה יחסית. יצירת דפים באתר MOSS באמצעות הדפדפן, היא פעולה שעשויה לקחת זמן (זמן טעינת הדפים, ההקלדה וכן הלאה).

במקרה שלי, לדוגמא, אני נזקק לפתרון כזה, בכל פעם שאני מייצר הדגמה ללקוח, או עבור איזו הרצאה. הזנת דפים מרובים באמצעות ממשק הדפדפן של MOSS היא איטית ומסורבלת מדי. במקרה כזה, אני מייצר את התוכן באקסל, בצורה טבלאית ומהירה, ואז משתמש בקוד כדי להעביר את המידע ל- MOSS.

דגשים ביצירת דפים

דפים(pages) הם למעשה פריטי רשימה מיוחדים. קיימים כמה הבדלים בין דפים לפריטי רשימה: לדפים יכולות להיות גרסאות, ולכן יש צורך להוציא אותם (check out) ולהכניס אותם בסיום העריכה; יצירת דף מייצרת דף aspx “אמיתי” ב- MOSS; וכן הלאה.

כדי להקל על העבודה, משתמשים בגרסה מיוחדת של האובייקט SPWeb – האובייקט SPPublishingWeb – גרסה זו מייצגת אתר Publishing וחושפת תכונות ופעולות יחודיות לסוג זה של אתרים (למשל, תכונה החושפת את התיקיה Pages).

חשוב לזכור להשתמש באובייקט PublishingPage לצורך יצירת הדף החדש, לאובייקט זה קיימות פעולות של Check-In ו- Publish.

הרחבת הקוד ליצירת דפים מרובים

כאשר מייצרים דפים מרובים, הקוד לא משתנה בהרבה (מיצירת עמוד בודד). השינוי העיקרי הוא ייבוא המידע ממקור הנתונים שלכם (למשל אקסל, או קובץ XML), ואז “עטיפת” הקוד ליצירת הדפים בלולאה.

שימו לב שאת יצירת המצביעים לאוסף האתרים ולאתר (SPWeb ו- SPSite), תשאירו מחוץ ללולאה. אין צורך לייצר ולהרוס את המופעים שוב ושוב.

ההבדלים בין רמות האבטחה השונות מתבטאים, בזכויות גישה למשאבים מקומיים, גישה ל- Databases וכן הלאה.

רמת האבטחה נקבעת בקובץ ה- web.config של כל אפליקציה, והיא מגדירה עבור Web Parts ועבור כל קוד פרטי, את זכויות הגישה שלו למשאבים מקומיים.

מתי צריך רמות אבטחה שונות?

בחלק גדול מהפורטלים הפנים ארגוניים שאני מגיע אליהם, אני מגלה שהגדירו את רמת האבטחה על Full Trust.

תוכניתנים ומיישמי MOSS בדרך כלל לא רוצים את “כאב הראש” שכרוך ביישום רמת אבטחה ייחודית, ואת ההשלכות מרמת אבטחה ספציפית (למשל, הצורך לחתום קוד, והצורך להגדיר הרשאות למקורות מידע). כפתרון, הם מורידים את רמת האבטחה הכללית, ומגדירים את הפורטל כולו כ- Full Trust.

לעיתים, ההגדרה הזו בעייתית. פורטל ארגוני יכול להיפרס עבור ארגון גדול, הדורש מידור בין היחידות השונות. מצב בעייתי נוסף הוא כאשר הפורטל מכיל תכנים רגישים, או סודיים של הארגון, ועמדות הגישה עשויות להיחשף לגורמים זרים (למשל, עמדת עבודה הנשארת פתוחה לשימוש כלל העובדים, וכד’).

הגדרת רמת אבטחה מותאמת אישית

הגדרת רמת אבטחה מותאמת אישית, הינה תהליך פשוט למדי, בעל שלושה שלבים:

• יצירת קובץ ההגדרות
• עריכת הקובץ והוספת הנחייות לכל Web Part או מקטע קוד נדרש
• הגדרת רמת האבטחה החדשה ב- web.config

יצירת קובץ ההגדרות

כתיבת קובץ הגדרות מאפס היא משימה לא פשוטה, ומיותרת. כדאי להתחיל מקובץ הגדרות קיים, ולשפר אותו. לא מדובר בערכית הקבצים הקיימים, אלא בעריכת העתק שלהם.

חשוב: אל תמחקו את הקבצים המקוריים. צרו העתק של הקובץ, ועיבדו עליו.

בהנחה שהתקנת את MOSS במקום ברירת המחדל, קבצי ההגדרות יימצאו בתיקיה:

C:\Program Files\Common Files\Microsoft Shared\web server\extensions\12\CONFIG

קיימים קבצי הגדרות עבור שתי רמות האבטחה: wss_minimaltrust.config ו- wss_mediumtrust.config עבור רמת האבטחה הנמוכה והבינונית בהתאמה.

בחרו את רמת האבטחה ממנה ברצונכם להתחיל, שכפלו את הקובץ, ותנו לו שם משמעותי. לצורך הדוגמא, נשכפל את wss_mediumtrust ונקרא לו: wss_custom_mediumtrust.config.

עריכת הקובץ והוספת Web Parts

בקובץ הקונפיגורציה, כל מקטע קוד שצריך רמת הרשאה מורחבת, מוגדר באמצעות ענף (Node) בשם CodeGroup. כדי להוסיף מקטע חדש, יש להוסיף ענף חדש, באופן הבא:

חשוב: כל מקטעי הקוד הפרטיים, צריכים להיות מוגדרים לאחר הענף המגדיר את
“ FirstMatchCodeGroup“ (שורה 52, בקובץ המקורי).

מבנה הענף הינו:

<CodeGroup
class=”UnionCodeGroup”
version=”"
PermissionSetName=”FullTrust”
Name=”Your descriptive name here”
Description=”Free text description.”>
<IMembershipCondition
class=”StrongNameMembershipCondition”
PublicKeyBlob=”033200040480000094000000060200340024000
052534131000400000100010007D1FA57C4AED9
F0A32E84AA0ADEFD0DE9E8FD6AEC8F87FB03766
C83DC99921EB23BE79AD9D5DAA1DD9AD2361321
02900B723CF980957FC4E177108FC607774F29E
8320E92EA05ECE5E821C0A5ECE8F1645C4C0C93
C1AB99285D622CAA652C1DFAD63D745D6F2DE5F
17E5EAF0FC4963D261C8ABDAB6518206DC09334
4D5AD293″>
</IMembershipCondition>
</CodeGroup>

חלקי הענף אותם יש לשנות, הם:

Name – שם הקוד או ה- WebPart. טקסט חופשי, שניתן יהיה לזיהוי בקלות.

Description – תאור מקטע הקוד או ה- WebPart. טקסט חופשי.

PublicKeyBlob – ה- Public Key של הקוד החתום. הערך צריך להיות בשורה אחת רציפה, ללא רווחים וללא שבירות שורה. שבירות השורה כאן, הן לצורך נוחות הקריאה.

ניתן להשיג ערך זה, באמצעות שימוש בפקודה SN המגיעה עם VS.Net

בדרך כלל תמצא הפקודה ב-

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin

(בהנחה שהתקנתם את VS בכונן C במיקום ברירת המחדל)

בכדי לקבל את המפתח הציבורי, השתמשו בתחביר: SN -Tp yourWebPart.dll
הפקודה היא Case Sensitive (כלומר, ל- -Tp ול- tp- יש משמעויות שונות).

אפשרות נוספת, היא שימוש ב- Dot.Net reflector, פשוט “זירקו” את ה- DLL אל חלון התוכנה, ובפרטי ה- DLL יופיע המפתח.

שינוי קובץ ה- web.config

חשוב: לפני שינויים ב- web.config יש לבצע גיבוי של הקובץ המקורי.

יש לבצע שני שינויים עיקריים: הוספת רמת האבטחה החדשה, וקביעה כי זו רמת האבטחה בשימוש.

ראשית יש להוסיף את רמת האבטחה החדשה. מאתרים את הענף: <securityPolicy>

בתוכו קיימים ענפים עבור כל רמת אבטחה מוגדרת. שימו לב, שאין ענף עבור רמת האבטחה Full, מאחר וזו מגיעה מ- ASP.Net

עבור רמת האבטחה החדשה, יש להגדיר ענף “trustLevel” חדש, באופן הבא:

<trustLevel name=”WSS_Custom_Medium” policyFile=”X:\SomePath\wss_custom_mediumtrust.config ” />

כאשר ב- name אפשר לתת כל שם ייחודי ומובן, ללא רווחים. וב- policyFile יש לציין את הנתיב המלא לקובץ שיצרתם.

השלב הבא הוא הגדרת רמת האבטחה החדשה. אתרו ב- web.config את השורה הבאה:

<trust level=”WSS_Minimal” originUrl=”" />

השורה הנ”ל מופיעה בקובץ המקורי, ייתכן שאצלכם מוגדרת כבר רמת אבטחה שונה.

שנו את ערך התכונה “level” לשם שנתתם לרמת האבטחה בשלב הקודם.  בדוגמא, השתמשתי בשם “WSS_Custom_Medium” ולכן השורה שלי תראה כך:

<trust level=”WSS_Custom_Medium” originUrl=”" />

לאחר ביצוע כל השינויים, יש לבצע IISReset ולבדוק את פעילות האתר.