WSUS یا WINDOWS SERVER UPDATE SERVICE (بخش دوم)

برای مطالعه بخش اول WSUS اینجا کیلیک کنید.

کنسول wsus را باز میکنیم اما مبینیم که این کنسول باز نمیشود. برای Troubleshooting یکی از کارهایی که میکنیم چک کردن IIS است.

توجه داشته باشید که اگر سرویس IIS ، Start نباشد کنسول WSUS باز نخواهد شد. Inetmgr را چک میکنیم و میبینیم سرویس آن start است و مشکلی ندارد. برمیگردیم به کنسول wsus ، اینبار دستی connect میکنیم (به localhost یعنی خودش یا 127.0.0.1).

باز هم باز نمیشود:

سپس:

به پورت 8530 آدرس مربوطه نمیتواند وصل شود.

با توجه به Error نمایش داده شده سرویس مربوط به SQL هنوز Start نشده است.

کنسول services.msc را باز میکنیم و همانطور که مشاهده میکنید سرویس Windows Internal Database ، Start نیست:

آن را Start میکنیم و مشکل حل میشود.

در بخش Update  مایکروسافت چند بخش Filter View قرار داده است:

مثلا  از لیست آپدیت ها در Security update فقط آپدیت های مربوط به security را نمایش میدهد. ما خودمان هم میتوانیم Filter view بسازیم. برای مثال وقتی روی Security updates کلیک میکنیم باید Catalog یا لیستی از Security update ها ببینیم.

توجه داشته باشید که آپدیت ها زمانی شروع به دانلود شدن میکنند که اصطلاحا Approve شوند. مادامی که آپدیتی Approve نشود به صورت پیش فرض دانلود نمیشود. حالا اگر ما آپدیت را Approve کردیم چه زمانی دانلود میشود؟ wsus همیشه در حال دانلود است. اما اگر  کل آپدیت ها را Approve کنیم و حجمشان 50GB شود و از همان لحظه شروع کند به دانلود کند قطعا روی پهنای باندمان تاثیر میگذارد.

در ویندوز سرویسی به نام BITS یا Background Inteligent Transfer Service. Bits وجود دارد، Available Space ئه پهنای باند اینترنت را محاسبه میکند. یعنی شما 5MB پهنای باند اینترنت دارید و در حال حاضر 4MB آن از طرف کاربران در حال استفاده است و 1MB آن بلااستفاده است، BITS شروع به استفاده از 1MB میکند . یعنی bits همواره پهنای باند آزاد را محاسبه میکند. Wsus به همین روال و با استفاده از BITS دانلود های خود را انجام میدهد و همواره از پهنای باند آزاد شبکه استفاده میکند. وقتی WSUS را نصب میکنیم یکی از Feature هایی که نصب میشود  BITS است.

هر آپدیتی را که میخواهیم select میکنیم و روی آن کلیک راست میکنیم و Approve را میزنیم. سپس پنجره ای باز میشود که میپرسد این آپدیت ها را به کی Approve میکنی؟

ما میتوانیم کامپیوتر های شبکه را در گروه های  ای که خودمان درست میکنیم دسته بندی کنیم. وقتی آپدیت را Approve میکنیم این آپدیت فقط به گروه هایی که ما میگوییم offer میشود. اولین مزیتی که این کار دارد ایجاد یک محیط Pilot است. یعنی آپدیت ها را اول در محیط Pilot نصب میکنیم و اگر مشکلی به وجود نیاورد آن را در کل شبکه propagate میکنیم.  این توصیه خود مایکروسافت است که آپدیت ها در محیط پایلوت ابتدا تست شوند و بعد روی همه سیستم های شبکه Propagete شوند. ضمنا توصیه دیگر مایکروسافت این است که باید همواره آپدیت های Security و Critical را نصب کنید و آپدیت های دیگر را در محیط pilot تست کنید. چون اگر با نصب آپدیت های security و critical مشکلی پیش بیاید این مشکل قطعا از جای دیگری است و باید آن را برطرف کرد و آپدیت های مذکور باید تحت هر شرایطی نصب شوند .

کلیه آپدیت ها هم در مسیری که موقع نصب wsus  دادیم ذخیره میشود.

آپدیت ها در پوشه ی bold شده ذخیره میشوند.

همانطور که گفتیم خودمان هم میتوانیم Update view درست کنیم. برای اینکه خودمان بتوانیم این کار را انجام دهیم:

روی New Update View کلیک میکنیم:

مطابق شکل زیر تیک گزینه ای را که میخواهیم میزنیم و روی any classification کلیک میکنیم.

از پنجره ی باز شده آپدیت هایی که میخواهیم در این View باشند را انتخاب میکنیم.

زمانی هم که روی View ئه update کلیک میکنیم آمار کلی آپدیت ها را مشاهده میکنیم.

بخش Update را میبندیم و روی گزینه ی Computers کلیک میکنیم. در این بخش تمام کامپیوترهایی که خودشان را به wsus معرفی کردند آورده میشود.

که در اینجا هیچ کامپیوتری عضو نیست. نکته ای که وجود دارد این است که کامپیوترها را چگونه میتوانیم به wsus معرفی کنیم؟

از ویندوز 2000 ئه service pack 3 به بعد امکان windows update به ویندوز اضافه شد. که تنظیمات آن هم در Control Panel و windows Updates وجود دارد.

در اینجا بخشی وجود ندارد که  کامپیوتر آپدیت ها را از wsus بگیرد و پیش فرض از سایت مایکروسافت میگیرد. تنها راه این کار (معرفی کردن یک کامپیوتر به wsus کانفیگ چند Policy است). این policy ها میتوانند به صورت Locally روی یک کامپیوتر اجرا شوند و همچنین این Policy ها میتوانند از طریق Active Directory اعمال شوند. این کار به صورت زیر صورت میگیرد:

از gpedit.msc به dreil down زیر میرویم:

در اینجا یکسری policy وجود دارد که به wsus ارتباط پیدا میکنند. ما روی policy زیر کلیک میکنیم:

policy را Enable میکنیم و تنظیمات را روی آن انجام میدهیم:

این گزینه ها همان گزینه هایی هستند که ما بعضی از آنها را در windows update در بخش control panel میبینیم.

تنظیمات را به صورت زیر انجام میدهیم:

دومین Policy ایی که باید config کنیم policy زیر است:

در این قسمت  باید آدرس wsus را بدهیم. با ساختاری که میبینید آدرس wsus را میدهیم :

مشخص میکنیم آپدیت ها را از کجا بگیرد و در بخش پایین آن باید مشخص کنیم  Statistics یا آمارها را به چه کسی بدهد:

اگر به یاد داشته باشید گفته بودیم میتوانیم یک wsus داشته باشیم که آپدیت ها را دانلود نمیکند بلکه فقط آمار میگیرد. در اینجا میتوانیم آدرس این wsus را بدهیم و هم میتوانیم یک wsus داشته باشیم :

ضمنا دستور gpupdate /force در انتهای کانفیگ policy ها فراموش نشود.

این وبسایت هم در IIS داریمش:

که همانطور که مشاهده میکنید بعد از انجام این مراحل کامپیوتر مربوطه به لیست wsus اضافه شده است:

اگر یک کامپیوتر اتوماتیک در اینجا اضافه نشد در side ئه Client میتوانیم یک command ای بزنیم. این دستور باعث میشود که کامپیوتر ما فورس شود که همین الان برود و خودش را به wsus معرفی کند:

در آدرس زیر یک فایلی به نام WindowsUpdate وجود دارد که در آن آمار آپدیت های کامپیوتر قرار دارد:

آن را باز میکنیم:

حالا میخواهیم مطمئن شویم که آیا ویندوز ما میرود سوالاتش رو از wsus ای که بهش معرفی کردیم بپرسد؟ برای این کار IP ی wsus را در این فایل Find میکنیم؛ اگر روی این IP سوییچ کرده باشد باید در اینجا پیدا شود:

البته بهتر است به جای دستور بالا از دستور زیر استفاده کنیم:

میتوانیم روی All Computer از کنسول wsus کلیک کنیم و گزینه ی Add Computer Group را بزنیم:

و یک گروه اضافه میکنیم:

و میتوانیم به همین صورت گروه های مختلف را Add کنیم:

حالا میتوانیم کامپیوترها را در گروه های مختلف عضو کنیم. همچنین میتوانیم آپدیت ها را نیز برای گروه هایی که میخواهیم Approve کنیم:

در تصویر زیر یک آپدیت را Approve کردیم و بعد میپرسد به چه کسی Approve اش میکنید؟

ادامه دارد . . .

نویسنده :مهندس محمد آجورلو