הגדרות פרוקסי ב-WSUS נעלמות...

הפעם פוסט קצר על משהו שנתקלתי בו לפני מספר ימים.

מכיוון שעובדים אצלנו ברשת סגורה, ה-WSUS  פונה לשרת Proxy בשביל להוריד עדכונים.

פנו אלי עם תקלה שלא מבינים את מקורה - הגדרות ה-Proxy היו נעלמות כל יום בשרת ה-WSUS.

מסמנים את ה-V, עושים סינכרון ידני, הכל עובד תקין, למחרת באים ואין הגדרות Proxy...

למה זה קורה?

כמובן שהחשוד הראשוני היה ה-SCCM. אנחנו עובדים עם SCCM בשביל להפיץ עדכונים לשרתים ולכן שרת ה-WSUS הוא גם ה- SUP (Software Update Point) של SCCM.

לפיכך, ה-SCCM  מנהל את ההגדרות ובמידה ולא מגדירים פרוקסי ב-SCCM ההגדרות ב-WSUS ישתנו בהתאם.

כדאי לשנות נכנסים להגדרת ה-SUP  ומוסיפים את ה-Proxy.

לאחר ההגדרה הזו הכל יעבוד כשורה.

תשתית App-V

שלום לכל אותם חמשת האנשים שקוראים את הבלוג שלי, אתחיל בהתנצלות על כך שלא רשמתי הרבה זמן אבל אתם יודעים…תירוצים רגילים של עבודה, חו"ל, לימודים וכמובן מחאה.

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

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

לינקים רלוונטיים -

כאשר רוצים להשתמש ב App-V קיימות מספר אפשרויות וחשוב שנכיר כל אחת מהן על מנת שנוכל להתאים את התשתית לצרכי הארגון.

שרטוט מרשים של מיקרוסופט בו ניתן להתרשם
מכל האפשרויות השונות לפריסת App-V בשילוב
אחת עם השניה.

יאללה מתחילים…

Standalone

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

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

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

יתרונות -

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

חסרונות -.

• לא ניתן לניהול.
• האפליקציות לא מתעדכנות.
• אין אפשרות להפיק דוחות.

Streaming

שרת App-V אחד או יותר. בשיטה זו האפליקציות מאוחסנות על השרת ו"זורמות" (זה התרגום של streaming מכאן והלאה זה המונח שאשתמש בו) אל הקליינטים.

בשיטה זו לרוב נשתמש ב SCCM (מגרסה R2 SP1 ומעלה, גרסה 4.6 דורשת SP2) לצורך ניהול והפצת האפליקציות.

במידה ובארגון מוטמעת כבר מערכת SCCM אז הארכיטקטורה הזאת היא אפשרות טובה, SCCM מגרסה R2 SP2 עובד בצורה מלאה עם App-V ומאפשר לנצל את התשתית ואת הידע שכבר יש בארגון לצורך הפצת אפליקציות ווירטואליות.

מה זה אומר אפליקציה זורמת – Streaming? כאשר יש דרישה לאפליקציה ווירטואלית מתחיל תהליך של העברת ה-FB1 – כלומר Feature block 1, זהו החלק הראשון וההכרחי בשביל פתיחת האפליקציה. השאר, כלומר ה-FB2, ירד לקליינט לפי דרישה.

לדוגמה, כאשר נארוז Microsoft Visio 2010 לא נצטרך לחכות שכל החבילה ששוקלת מעל 300 מגה תטען למחשב, רק החלק ההכרחי יטען (FB1 זוכרים?) והאפליקציה תהיה מוכנה לשימוש תוך שניות.

יתרונות -

• חסכון במשאבים – לא דורש שרת SQL, ניתן להתקין על גבי שרת הSCCM.
• הזרמת האפליקציות על גבי HTTP או BITS.
• מאפשרת הורדה-על ידי –דרישה.
• "רכיבה" על גבי תשתית ה-SCCM.
• שינוים ועדכונים שמבצעים על האפליקציה הווירטואלית בשרת יופצו גם למשתמשים.

חסרונות -

• דורש מינימום שני העתקים של קובץ ה-SFT על שרת ההפצה.
• דורש נפח תעבורת רשת גבוהה.
• במקרה והDP לא זמין לא ניתן להריץ אפליקציה ווירטואלית.

Full Infrastructure

בשיטה זו נשתמש בלפחות שרת App-V  מרכזי אחד שמתפקד כ-App-V Management Server.

שרת ה-Management יכול וגם בדרך כלל משרת גם כשרת ה-Streaming כך שהאופציה להוסיף שרתי Streaming היא אופציונלית לגמרי ותלויה בצרכים.

יתרונות -

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

חסרונות -

• יקר (דורש לפחות שרת App-V יעודי ושרת SQL).
• עבודה רק דרך קונסול של App-V Management Server.
• מסובך יותר לניהול ודורש ידע או הכשרה.

סיכום

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

המידע והתמונות נלקחו מה-Infrastructure Planning and Design Guide for Microsoft App-V 4.6 של מיקרוסופט. זהו תיעוד מקיף לגבי תשתית הApp-V.

מקווה שהעשרתי את הידע שלכם כפי שאני למדתי תוך כדי כתיבת הפוסט.

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

נתראה בפוסט הבא.

מדריך להתקנת SCCM 2012 Beta 2

אז... הגרסה הסופית של המוצר מתקרבת וכבר לא ניתן להישאר אדישים לכך.

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

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

דרישות קדם :

• SCCM Schema Extention
• .NET Framework 4.0
• Windows Server 2008 (64Bit) (זה אומר גם R2)
• SQL Server 2008 SP1 with CU10 (64Bit)

כדי להרחיב את הסכמה (Schema) צריך להריץ את קובץ ה-extadsch.exe מתוך ספריית ההתקנה עם יוזר שיש לו הרשאת Schema Admin.

כדאי לשים לב שרק גרסת ה-SQL שרשומה נתמכת. כלומר, לא ניתן להתקין על SP2 או R2. אני מאמין שעד ה-RTM כבר תהיה תמיכה אבל כרגע זה המצב.

אם התקנתם את גרסת ה-SQL המדויקת ומצאתם את עצמכם מתוסכלים מול חלון השגיאה הזה –

שימו לב... צריך להפעיל שני פרוטוקולים בתוך שרת SQL:

•   TCP/IP
• Named Pipes

מדריך כיצד להפעיל אותם ניתן למצוא כאן

כמו כן, צריך להתקין את הפיצ'רים הבאים של מערכת ההפעלה –

• Remote Differential Compression
• IIS 6 WMI Compatibility Component
• Background Intelligent Transfer Service

מערכות נתמכות :

• Windows XP Pro SP3, Windows XP Pro 64Bit SP2
• Vista Business, Enterprise, Ultimate, SP1, SP2, 32Bit & 64Bit
• Windows 7 Enterprise, Ultimate
• Windows Server 2003 SP2, Windows Server R2
• Windows Server 2008 Standard, Enterprise & Data Center, R2

חלון ההתקנה הראשי.

זה מה שמקבלים כשפותחים את הקובץ הראשי (splash.hta), כרגע זו לא גרסה סופית וחלק מהכפתורים לא עושים כלום. כדי להתחיל בהתקנה נלחץ על Install כמובן.

חלון ה-Welcome

Next...

אפשרויות התקנה

כאן צריכים לבחור מה ברצוננו לעשות, אנו נבחר באפשרות של התקנת שרת ראשי חדש (Primary Site server).

ניתן לבחור ב"Use typical installation options for a single server installation" וכך נצמצם למינימום את ההתערבות שלנו וההגדרות ימולאו כפי שהוגדר בברירת המחדל.

אנחנו כמובן לא נסמן את האפשרות הזאת.

תבחרו באפשרות הראשונה – Install a Configuration Manager Primary server.

הסכם הרישוי

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

עדכונים

מדי פעם יוצאים עדכונים לתהליך ההתקנה עצמו.

כאן יש לנו שתי אפשרויות :

1. להוריד עכשיו. תבחרו תיקיה והעדכונים ירדו לשם.

2. לבחור מיקום של עדכונים שירדו מראש. (ישנה אפשרות להוריד את העדכונים מכל מחשב שמחובר לרשת)

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

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

הגדרת מיקום ההתקנה ושם ה-Site

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

Site code – מורכב משלוש אותיות או מספרים. זה המזהה הראשי של האתר (Site).

Site name – אין הגבלה על מספר תווים כאן, מומלץ לרשום תיאור קצר.

Installation folder – מיקום התקנת הקבצים. מומלץ להתקין את המערכת על כונן אחר מהסיסטם. (בגלל שזה מעבדה, אני נשאר עם כונן C)

תשאירו את ה-V ליד האפשרות להתקין את הקונסול. אני לא רואה סיבה לא להתקין את הקונסול על השרת הראשי...

אתר ראשי

כאן ניתן לבחור האם השרת יצטרף לסביבה של שרתי SCCM ואז כאן נכניס את שם שרת ה-SCCM הראשי או שזה שרת מה שנקרא "עומד לבד" (כן אני אוהב לעברת דברים...) כלומר הוא יהיה הראשי (לאחר מכן יהיה ניתן לצרף אתרים אחרים מתחתיו). במעבדה נבחר באפשרות השנייה – Primary site will be installed as a standalone site.

חיבור לשרת SQL

במידה והתקנתם את שרת ה-SQL באופן תקין, השלב הזה קל…

בשדה ה-SQL Server תרשמו את השם המלא של השרת שבו רץ הSQL ותתנו להתקנה למלא את השדות הנותרים.

SMS Provider

SMS Provider – רכיב WMI אשר כותב וקורא ממסד הנתונים של ה-SCCM. ניתן להתקין אותו בכל שרת אשר שייך למערכת. במעבדה בחרתי להתקין לוקאלי על שרת ה-SCCM.

דרך תקשורת לקליינטים

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

במעבדה תבחרו באפשרות השנייה – Site roles can be individually enabled to allow either HTTP or HTTPS client communication.

Site System Roles

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

שיתוף חווית משתמש

זה בטה… Next…

סיכום ההגדרות

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

בדיקת דרישות קדם

רגע לפני ההתקנה – בדיקה שכל דרישות הקדם של ההתקנה מותקנות ומוגדרות כראוי.

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

על השרת שלי לא מותקן WSUS (או WSUS Console) ולכן קיבלתי אזהרה על כך. ממשיכים…

התקנה

לוחצים Begin ומחכים… ומחכים… המערכת מתקינה את עצמה.

בסיום ההתקנה זה יראה ככה:

שימו לב שהכול ירוק ואף רכיב לא נכשל בהתקנה.

לאחר סיום ההתקנה במידה נשאר רק לפתוח את הקונסול (לחיצה על Close תפתח את הקונסול במידה ולא ביטלתם זאת)

בהצלחה!

שלום עולם

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

אז ממש בקצרה: אני עובד בארגון גדול (1500 משתמשים, 1000 שרתים) כאיש סיסטם 3 שנים,

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

כאשר התחלתי לעבוד על המערכת, השימוש בSCCM היה רק במודל הדוחות והמלאי. בהמשך הגיעה דרישה לנהל ולהפיץ עדכונים בדרך חכמה יותר ומערכת SCCM הייתה אידיאלית לכך. מאז התחלנו להפיץ מערכות הפעלה ותוכנות דרך המערכת ואנו לומדים דרכים חדשות להשתמש במערכת (כרגע הכלים של MDOP קורצים לנו...).

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

אז, נתראה בקרוב...