WSUS-ის სინქრონიზაციის პროქსის კონფიგურაცია
WSUS-ის სინქრონიზაციის მონაცემები და საბოლოო წერტილი თავად WSUS-ის კონსოლში დააყენეთ, ნაცვლად ადმინისტრატორის ბრაუზერზე დაყრდნობისა ან ამ პარამეტრის კლიენტის პოლიტიკად მიჩნევისა.
არსებულ WSUS სერვერზე სინქრონიზაციის პროქსი თავად WSUS-ის შიგნით დააკონფიგურირეთ. ადმინისტრატორის ანგარიშით მომუშავე ბრაუზერის სესია არ ამტკიცებს, რომ სინქრონიზაციის სერვისს იგივე მარშრუტი ან იგივე მონაცემები აქვს.
WSUS-ის ადმინისტრირების კონსოლში გახსენით პარამეტრები, შემდეგ განახლების წყარო და პროქსი სერვერი. პროქსის ჩანართზე ჩართეთ პროქსის გამოყენება სინქრონიზაციისთვის და მიუთითეთ მსმენელის სერვერის სახელი და პორტი; თუ Microsoft Update-ის ტესტი საჯარო პროქსებს უშვებს და პროქსის მონაცემები დაყენებული არ არის, აირჩიეთ HTTP კანდიდატი HTTP პროქსების სიიდან.
თუ ამ პროქსისთვის კონკრეტული ანგარიშია საჭირო, შეიყვანეთ მომხმარებელი, დომენი და პაროლი WSUS-ის მონაცემების ველებში. დომენის ველი უნდა ასახავდეს იმ ანგარიშის აწყობას, რომელიც პროქსის ადმინისტრატორმა მოგაწოდათ; ის სულაც არ არის პროქსის ჰოსტის სახელის საჯარო DNS სუფიქსი.
Microsoft ამ პარამეტრს აღწერს როგორც WSUS-ის სინქრონიზაციებზე გავრცელებულს, მათ შორის ზემოთ მდგარ WSUS სერვერთან ან Microsoft Update-თან სინქრონიზაციას. ის არ აყენებს ყოველი ქვედა კომპიუტერის ბრაუზერს ან მის Windows Update კავშირს.
კონსოლი ასევე ცალსახად გვთავაზობს Basic ავთენტიფიკაციას. მოეკიდეთ მას როგორც ავთენტიფიკაციის არჩევანს და არა როგორც ზოგად მოსანიშნ ველს, რომელმაც შესვლა უნდა იმუშაოს: Microsoft აფრთხილებს, რომ ამ მექანიზმით პაროლი დაშიფვრის გარეშე იგზავნება.
როცა სინქრონიზაცია მაინც იშლება, ჩაწერეთ დაყენებული განახლების წყარო და მარცხის ეტაპი. მიუწვდომელი პროქსის მსმენელი, პროქსის ავთენტიფიკაციის უარყოფა და ზემოთ მდგარ სერვისამდე მისვლის შემდეგ წარმოქმნილი ჩავარდნა სხვადასხვა შესწორებას მოითხოვს. ბრაუზერში მომუშავე პაროლის ხელახლა შეყვანა ცოტას ამბობს, სანამ WSUS მოსალოდნელ პროქსის ანგარიშს არ გამოიყენებს.