בעיות בסביבת Terminal Services

Decoder

New member
בעיות בסביבת Terminal Services

ישמתי GP פרטני על שרתי ה-Terminal של Software Restriction ומאז לוקח לאפליקציות האופיס בשרת כמה שניות לעלות. זה מתבטא בזה שכאשר משתמש מפעיל את קיצור הדרך עד להצגת מסך הלוגו של תוכנת הוורד(Splash Screen) למשל, לוקח בערך 5-8 שניות עד שהתוכנה עולה. כאשר אין SR ב-GP הספציפי, הבעיה נעלמת. מדובר בסביבה של 2003 כולל DCים ואופיס 2003. ניסיתי להריץ RegMon ו-FileMon אין רמזים לפתרון. שאלתי היא האם מישהו נתקל בבעיה עם Setup דומה של SR? לא נתקל? טיפים משהו...?
 

antidot

New member
לא תמיד ברור ../images/Emo8.gif

מה גם שלא עבור כל TS הloopback מתאים. בכל מקרה, הגדרת לפי הhash או לפי UNC ? אם זה לפי הhash, תקח בחשבון שהשרת בכל הפעלה של אפליקציה מחשב את את הchecksum של האפליקציה - דבר שיכול לקחת זמן במידה והEXE גדול. בכל מקרה, הנה לינק לא רע על דברים שיש להיות מודע אליהם בכל הקשור לSR: http://mcpmag.com/columns/rss.asp?editorialsid=690
 

Decoder

New member
תגובה

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

antidot

New member
מעניין

לפי UNC זה אמור להיות הכי מהיר. ניסית להשוות עם אותו דבר רק לפי הhash ? לא שיחקתי יותר מדי עם SR - לא חסיד גדול של האופציה הנ"ל. מעדיף דרכים אחרות להגביל משתמשים.
 

Decoder

New member
תגובה

התקלה נגרמת מתוצאה שבכלל חל SR. גם אם נעביר את המצב ל-Allowed התופעה תמשיך לקרות. איזה דרכים היית מעדיף כדי להגביל משתמשים?
 

antidot

New member
שאלה טובה...

אפשר לגשת לזה כמו בפקודת מבצע: מטרה, משימה, שטח, אוייב, כוחותינו
מטרה: הקמת סביבת עבודה אופטימלית ומתן אפשרות ללקוח הקצה לבצע את המשימות היומיות שלו תוך שמירה ואבטחה מירבית על מערכות אירגוניות. משימה: הקמת סביבת TS וקינפוג השרת בצורה כזאת שמשתמש הקצה לא יוכל לבצע דברים מעבר למה שהוגדר לו ו/או הוא רשאי. שטח: שרת TS אוייב: משתמש קצה כוחותינו: מנהל רשת מתוגבר בAD ו-GPO הרי מה בסופו של דבר אנחנו רוצים ? למרות הדעה הרווחת, אנחנו לא מניאקים ולא נהנים להתעלל במשתמשים (טוב, נו... אולי קצת). מצד שני, אנחנו מודעים לכך שבסביבה שלא הוגדרה נכון המשתמש יכול לגרום לנזק ולפגוע בעבודה שוטפת של אחרים. SR מתיימר לתת סביבה דרקונית למדי ולדעתי הדבר מיותר. דוגמא פשוטה: בXP העלימו את האייקון של AD מnetwork browser כי הרבה חברות טענו שזה חושף את המבנה של AD לכלל המשתמשים. אם נחשוב על זה שניה, נבין שזאת שטות גמורה - כל מי שמתעניין במבנה הAD, אמור להיות מספיק חכם בשביל להיות מסוגל להריץ שאילתת LDAP ולקבל (לרב) הרבה יותר ממה שהGUI מאפשר. אם מנתחים נכון את החלק של security בGPO, אפשר רק ע"י הגדרות נכונות ב user rights assignment/security options לחסום את רב הנזק שהמשתמש יכול לגרום. השאר הוא ניקיון קוסמטי: להעלים אייקונים ותפריטים מיותרים, להשאיר על הdesktop רק את הדברים הנחוצים וכו'. הרי תכלס, כל הכלים שבעזרתם ניתן לגרום נגק אפשר להריץ מcmd. ברגע שלמשתמש יש גישה לprompt, תאורטית, הוא יכול לעשות המון דברים אם המערכת תאפשר לו - וכאן נכנס הנושא של user rights/security options. בכלל, מדיניות דרקונית לדעתי יכולה רק לפגוע בתפוקה של העובד - כולנו יודעים שזה בלתי אפשרי לעסוק אך ורק בדברים הקשורים לעבודה במשך היום. אז למה לנסות לטמטם את משתמש הקצה ?
 

Decoder

New member
תגובה

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