הערה
גישה לעמוד זה דורשת אישור. אתה יכול לנסות להיכנס או לשנות תיקיות.
גישה לעמוד זה דורשת אישור. אתה יכול לנסות לשנות מדריכים.
יישומי Customer Engagement (Dynamics 365 Sales, Dynamics 365 Customer Service, Dynamics 365 Field Service, Dynamics 365 Marketing), מעניקים לך אפשרויות לבודד את הנתונים שלך ואת גישת המשתמש. עבור מרבית החברות, הוספה ושימוש במספר סביבות Power Platform מספקת את השילוב הנכון של פונקציונליות ונוחות ניהול. לארגונים עם ישויות נפרדרות שעויות לרצות ספריות ורשיונות נפרדים, מומלץ לשקול שימוש בדיירים מרובים. כל המשתמשים בדייר יכולים לגשת לסביבות מרובות. דיירים מרובים צריכים להזמין משתמשי דיירים אחרים כמשתמשים אורחים כדי לתת להם גישה.
שימושים של סביבות מרובות
סביבות דומות כעיקרון למורכבות גדולה יותר של עסק עם קומות שמאורגנות לפי הפונקציות העסקיות. התייחס לכל קומה בתוך הבניין כיישום (שירות/מכירות/שיווק, ניהול ספקים, ניהול עושר) וחשוב על כל יחידה בתוך קומה כסביבה למטרה ספציפית כגון ייצור, הדרכה, בדיקות ופיתוח.
דרושות סביבות מרובות כאשר יש צורך בבידוד של נתנוים, יישומי plug-in, זרימות עבודה או משאבי הניהול שקשה לבודד אותם בקלות באמצעות יחידות עסקיות.
פריסה מרובת סביבות
ללקוח טיפוסי יש דייר אחד בלבד. דייר יכול לכלול סביבה אחת או יותר; עם זאת, סביבה תמיד משויכת לדייר יחיד.
דוגמה זו משתמשת בשתי סביבות עבור שלושה צוותים: מכירות, שיווק ושירותים.
שיווק ומכירות משתפים סביבה כך ששניהם יכולים לגשת בקלות למידע על הפניות. לשירותים יש סביבה משלהם, כך שניתן לנהל כרטיסים ואחריות בנפרד מתוך קמפיינים ואירועים מכירות אחרים.
באפשרותך לספק גישה בקלות אל אחת מהסביבות או לשתיהן. משתמשים של שיווק ומכירות יכולים להיות מוגבלים לסביבה שלהם ואילו משתמשי השירות שהם בעלי גישה מורחבת יכולים לעדכן רשומות תמיכה של הסלמות הקשורות לחשבונות בשתי הסביבות.
אודות דייר יחיד עם סביבות מרובות:
כל סביבה בתוך דייר מקבלת מסד נתונים משלה של SQL.
נתונים לא משותפים בין סביבות.
ראה ב- נפח אחסון ב- Microsoft Dataverse איך משתפים אחסון בין סביבות.
הסביבות בדייר יחיד נוצרות כברירת מחדל במקום הגיאוגרפי שבו הן מלכתחילה נרשמו לחשבון. נוסף לכך, יוצר הסביבה יכול לבחור ליצור את הסביבה במיקום גיאוגרפי אחר; מיקומים גיאוגרפיים מורשים יוצגו לבחירת המשתמש. בנסיבות מסוימות המשתמשים יצטרכו לראות או לבחור את כל המקומות הגיאוגרפיים הנתמכים על ידי Power Platform.
צריכת אחסון מסוכמת ונמצאת במעקב על-פני כל הסביבות שמצורפות לדייר הלקוח.
אפשר להגדיר קבוצות אבטחה נפרדות עבור סביבות אם אתה רוצה לשלוט במי שיכול לראות ולגשת לסביבה.
משתמש מורשה יכול לגשת לכל הסביבות המשויכות לדיירים. השליטה בגישה היא על-ידי חברות בקבוצת אבטחה של סביבה.
מדוע להשתמש בסביבות מרובות?
להלן מקרי שימוש נפוצים עבור פריסה של סביבות מרובות. שקול את הדוגמאות האלה כאשר אתה מחליט על הפריסה הטובה ביותר המתאימה לדרישות החברה שלך.
ניהול נתונים ראשיים
בתרחיש זה, ערכת נתונים "ראשית" מספקת ניהול שינויים באמצעות מקור הנתונים הראשי המרכזי. גישה זו דורשת סינכרון של בסיס הנתונים הראשי לכל הסביבות, כך שלכל סביבה תהיה גישה לגירסה העדכנית ביותר של נתוני הליבה. ניתן לבצע את השינויים המבוקשים במידע ישירות בתוך המערכת הראשית. לחלופין, משתמשים יכולים לקבל גישה מפורשת למערכת הראשית או ללכוד את השינויים בסביבה המקומית, עם שינויים אלה שבסופו של דבר עוברים לסביבה הראשית.
דרישה שיש לבצע שינויים במיקום מרכזי יכולה לספק שליטה מרכזית בשינויים. לדוגמה, ניתן לבצע בדיקות נגד הונאות כדי להבטיח כי שינויים נעשים רק על-ידי צוות מרכזי ולא על-ידי צוותים מקומיים אשר עשויים להפיק תועלת מהשינוי, כגון שינוי מגבלות אשראי. דבר זה יכול לאפשר רמה שניה של שינוי הרשאות ואימות שמונעת את היכולת עבור אדם יחיד או קבוצה של אנשים שעובדים יחד לשתף פעולה בדרך של הונאה. העברת בקשה לצוות אחר, ללא תלות, יכולה לספק הגנה מפני הונאות פוטנציאליות.
אבטחה ופרטיות
ההבדלים מבחינת חקיקה אזורית, לדוגמה האיחוד האירופי (EU), או לאומית יכולים להביא לדרישות שונות של אבטחת נתונים או שמירה על פרטיות נתונים באזורים שונים או במדינות שונות בפריסה. במקרים מסוימים, הגבלות משפטיות/חוקיות גורמות לכך שאין זה חוקי לארח נתונים מחוץ לגבולות של מדינה או אזור, וטיפול באתגר זה הוא קריטי במיוחד בסקטורים עסקיים מסוימים.
לדוגמה, חשוב על הגבלות בסקטור שירותי הבריאות מבחינת שיתוף מידע על מטופלים. חלק מתקנות האיחוד האירופי דורשות שכל מידע בנושאי בריאות אשר נאסף אודות אנשים שנמצאים באיחוד האירופי יהיה מתוחזק ומשותף רק בתוך גבולות האיחוד האירופי, בעוד נתונים דומים שנאספים לגבי אנשים בארצות הברית (ארה"ב) יישמרו בתוך גבולות ארה"ב. כמו כן שים לב למגבלות של סקטור הבנקאות על שיתוף מידע אודות לקוחות. בשוויץ, לדוגמה, התקנות מגדירות שאין זה חוקי לשתף מידע על לקוחות מחוץ לגבולות הלאומיים שלהם.
מדרגיות
בעוד שסביבה יחידה ניתנת להרחבה כדי לתמוך בצמיחת העסק של הלקוח, עם נפחי אחסון נתונים גבוהים מאוד או רמות מורכבות גבוהות, קיימים שיקולים נוספים. לדוגמה, בסביבות עם נפחי אחסון קיצוניים ו/או שימוש נרחב בתזמון שירותים, שינוי קנה המידה של שרת SQL עשוי לדרוש תשתית מורכבת ויקרה או קשה מאוד לניהול.
קיימים תרחישים רבים שבהם יש פיצול פונקציונלי טבעי בנושא דרישות יכולת. במקרים כאלה, האצלת עומסי עבודה על-ידי יצירת תרחישי הרחבה המבוססים על פיצול פונקציונלי יכולה לספק נפחי אחסון גבוהים יותר באמצעות תשתית של סחורות.
הוספת סביבה למנוי שלך
לקבלת מידע על אופן ההוספה של הסביבה לדייר שלך, ראה יצירה וניהול של סביבות.
פריסה מרובת דיירים
עסקים גלובליים עם מודלים אזוריים שונים או מודלים שונים של מדינה יכולים להשתמש בדיירים כדי להתייחס להבדלים בגישה, בגודל השוק או בתאימות להגבלות משפטיות ולתקנים.
דוגמה זו כוללת דייר שני עבור Contoso Japan.
אין אפשרות לשתף חשבונות משתמשים, זהויות, קבוצות אבטחה, מנויים, רשיונות ואחסון בין דיירים. עבור כל הדיירים, ניתן לשייך סביבות רבות לכל דייר ספציפי. הנתונים אינם משותפים בין סביבות או דיירים.
אודות דיירים מרובים:
בתרחיש של ריבוי דיירים, משתמש מורשה המשויך לדייר יכול לגשת רק לסביבה אחת או יותר שממופה לאותו דייר. כדי לגשת לדייר אחר, יש להזמין משתמש כמשתמש אורח וייתכן שיהיה צורך להקצות לו רישיון נפרד.
כל דייר דורש מנהל(י) Microsoft Power Platform עם אישורי כניסה ייחודיים, וכל סניף דיירים ינהל את הדיירים שלו בנפרד במסוף המנהל.
סביבות מרובות בתוך דייר גלויות מתוך הממשק אם למנהל המערכת יש אפשרות גישה.
אין אפשרות להקצות מחדש רשיונות בין הרשמות דיירים. סניף הרשמה יכול להשתמש בהפחתת רשיון תחת הרשמה אחת ולהוסיף רשיונות להרשמה אחרת כדי להקל על זה.
אין אפשרות ליצור פדרציה של Active Directory מקומית עם יותר מדייר אחד אלא אם כן יש לך תחומים ברמה העליונה שעליך לאחד עם דיירים שונים (לדוגמה Contoso.com ו- Fabricam.com).
מדוע להשתמש בדיירים מרובים?
הסבה פונקציונלית
תרחיש זה קיים בדרך כלל בארגונים עם צרכים פונקציונליים חופפים אך נפרדים. כמה דוגמאות נפוצות:
ארגונים עם חטיבות עסקיות שונות, כל אחת עם שוק שונה או מודל פעולה שונה.
עסקים גלובליים עם מודלים אזוריים שונים או מודלים שונים של מדינה שמתייחסים להבדלים בגישה, בגודל השוק או בתאימות להגבלות משפטיות ולתקנים.
בסוגים אלה של סביבות עסקיות, לארגון לעתים קרובות תהיה הגדרת פונקציונליות נפוצה המאפשרת אזורים ספציפיים, מדינות או אזורים עסקיים שונים בדרגת התאמה לשפות אחרות לגבי:
לכידת מידע. לדוגמה, לכידת המיקוד בארצות הברית תתאים ללכידת קוד ה-Post בבריטניה.
טפסים, זרימות עבודה.
הפצה פיזית
פתרונות עסקיים שחייבים לתמוך במשתמשים שמפוזרים פיזית על פני מרחקים גדולים, במיוחד עבור פריסות גלובליות, באמצעות סביבה יחידה, עשויים שלא להתאים בשל ההשלכות (כגון השהיה WAN) הקשורות לתשתית שדרכה משתמשים מתחברים, שיש לה השפעה משמעותית על חוויית המשתמש. הפצת סביבות כדי לספק למשתמשים גישה מקומית יותר יכולה להפחית או להתגבר על בעיות הקשורות ל-WAN, שכן הגישה מתרחשת בחיבורי רשת קצרים יותר.
הוסף פריסה מרובת דיירים לרישוי רב משתמשים
עבור פריסה מרובת לקוחות, תצטרך תיקון מרובה לקוחות. תיקון מרובה לקוחות הוא תיקון בפועל להסכם רשיון רב משתמשים המשמש כדי לרכוש רשיונות. פנה אל נציג המכירות של Microsoft או למשווק כדי להשיג את התיקון.
אילוצים של ריבוי לקוחות
מנהלים המעוניינים לפרוס ולנהל לקוחות מרובים צריכים להיות מודעים לנקודות הבאות:
אין אפשרות לשתף חשבונות משתמשים, זהויות, קבוצות אבטחה, מנויים, רשיונות ואחסון בין דיירים.
אפשר לאחד תחום יחיד רק עם לקוח אחד.
כל לקוח חייב להיות בעל שמות משלו; אין אפשרות לשתף את טווחי השמות UPN או SMTP על-פני לקוחות.
אם קיים ארגון שמשתמש בגירסה המקומית של Exchange, לא ניתן לפצל ארגון זה על-פני מספר לקוחות.
רשימת כתובות כללית מאוחדת לא תתפרסם, אלא אם היא מנוהלת במפורש במורד הסינכרון.
שיתוף פעולה בין-לקוחות יהיה מוגבל לאיחוד של Lync ומאפייני האיחוד של Exchange.
לא ייתכן שתהיה אפשרות גישה שלSharePoint על-פני לקוחות. בעוד שייתכן שאפשר לפתור זאת באמצעות גישת שותפים, חוויית המשתמש משובשת וחלים היבטים של רישוי.
לא יכולים להיות חשבונות כפולים בדיירים או במחיצות ב- Active Direcotry מקומי.