Когато управлявате много компютри в една организация, наличието на централизирани контролери и под контрол Това прави разликата между чистото внедряване и абсолютен хаос. Вместо ръчно инсталиране на драйвери на всяка машина, най-ефективният подход е да се създаде добре организирано, достъпно от мрежата и лесно актуализирано локално хранилище за драйвери.
Освен опростяване на инсталациите от нулата, едно добро хранилище ви позволява поддържайте всички устройства актуализираниЩе разгледаме как да автоматизираме задачите за осигуряване, да работим с множество клонове и хранилища за код в инструменти като Visual Studio и дори да ги комбинираме с поредици от задачи или скриптове за внедряване. Нека видим как да настроим това локално хранилище за драйвери, как да го управляваме и как да извлечем максимума от него в многоекипна среда.
Какво е локално хранилище за драйвери и защо трябва да ви е грижа?
Локалното хранилище за драйвери е, по същество, централизирана папка на сървър Това е мястото, където съхранявате всички драйвери, които ще използвате за внедряване и поддръжка на вашите системи. В много пакети за управление (като например решенията за управление и сигурност на крайни точки), това хранилище се хоства по подразбиране на основния сървър, въпреки че можете да го разположите и на предпочитан сървър близо до клиентите.
Ключовото е, че това място е възможно най-достъпно UNC път (\\сървър\ресурс) както и чрез HTTP/HTTPS URL адрес. Много инструменти за осигуряване на хардуер (HII, Hardware Independent Imaging и подобни) изискват и двата метода за изтегляне на драйвери в зависимост от състоянието на оборудването, независимо дали е в предварителна инсталационна среда (персонализирайте OOBE с FlyOOBE) или ако вече има операционна система.
Това хранилище е това, което захранва последователности от задачи за изображения, скриптове за внедряване и процеси на актуализиранеВместо да вграждаме драйверите в самото изображение (което създава специфични изображения за всеки модел), ние работим с хардуерно независими изображения и оставяме драйверите в това централно хранилище.
Основни изисквания към хранилището на драйвери
Преди да създадете хранилището, е важно да сте наясно с нуждите на вашата инфраструктура, за да сте сигурни, че всичко работи правилно и екипите могат да го използват ефективно. Изтеглете драйверите без проблеми.
Първо, папката, в която ще запазите драйверите, трябва да бъде споделена в мрежа с... стабилен и добре дефиниран UNC пътСъщото това местоположение или копие на съдържанието трябва да е достъпно чрез URL адрес. Много реализации използват уеб сървър или самия сървър за управление, за да предоставят това съдържание през HTTP.
Концепцията за предпочитани сървъри или сървъри за огледално отразяване на съдържаниеТук посочвате на кой сървър искате да се намира хранилището с драйвери. В среди с множество сайтове е обичайно всеки главен офис да има свой предпочитан сървър, така че машините да не се налага... Изтегляне на драйвери през претоварена WAN мрежа.
Освен това има ключово техническо условие: всеки драйвер, който добавяте към хранилището Трябва да включите вашия .inf файлТози файл описва хардуера, поддържан от драйвера, пътищата за инсталиране, зависимостите и др. HII или инструментите за управление на драйвери не са базирани на изпълними файлове, а на... .inf файловете се използват за свързване на действителния хардуер с правилния драйвер..
Как се генерира базата данни с драйвери в хранилището?
След като сте поставили всички драйвери в правилната папка, инструментът за управление на драйвери на вашия пакет за осигуряване влиза в действие, който обикновено се нарича нещо подобно Управление на HII контролер или подобноТова е мястото, където всъщност превръщате тази папка в хранилище, използваемо от последователности от задачи.
Обичайният процес започва от главната конзола: достъпвате менюто на Инструменти > Осигуряване > Управление на драйвери (Точното име варира в зависимост от продукта, но процесът е много подобен.) След като стигнете там, обикновено имате бутон, еквивалентен на „Генериране на библиотека“ или „Създаване на база данни с драйвери“, който е това, което стартира всичко.
В съветника първото нещо, което трябва да направите, е да проверите дали Местоположението на хранилището е валиден UNC път.Ако файловете на драйвера са в различна папка, изберете правилната, като използвате бутона за преглед. След това проверете дали URL адресът, свързан с това хранилище, е правилен, тъй като клиентите ще го използват, когато са в среди, които позволяват само HTTP(S) трафик.
След като UNC пътят и URL адресът бъдат потвърдени, конфигурацията се запазва. В този момент инструментът HII започва обходете папката на хранилището и прочетете всеки .inf файлТова генерира файл с база данни (обикновено наричан drivers.db3 или подобен). Този файл позволява на системата да асоциира хардуерните идентификатори на всяко устройство с правилния драйвер без ръчна намеса.
В края конзолата показва съобщение, указващо общия брой намерени файлове и колко от тях са обработени. валидни контролериТова е подходящ момент да проверите дали броят на драйверите горе-долу отговаря на очакванията ви; ако разликата е много голяма, вероятно липсват .inf файлове или драйверите са неправилно пакетирани.
Всеки път, когато добавяте още драйвери към това хранилище, ще трябва повторете същия процес на генериране на библиотекаИнструментът ще анализира отново цялата папка и ще актуализира базата данни, за да включи новите драйвери, без да губи старите.
Актуализиране на съществуващо хранилище
Хранилището с драйвери не е статично; с течение на времето моделите на оборудване се променят, пускат се нови версии на драйвери и се появяват критични корекции на грешки. Ето защо е важно да имате ясна рутина за поддържайте базата данни с драйвери актуална.
Обичайният работен процес е доста прост: първо събирате новите драйвери от уебсайта на производителя или от официални хранилища, проверявате дали всеки пакет има своите правилно структуриран .inf файл и след това копирате тези файлове в същата папка в централното хранилище.
След като копирате, върнете се към конзолата за управление на драйвери и се върнете в раздела на Управление на HII контролерПроверявате дали UNC пътят и URL адресът са същите като тези, които вече сте използвали, и рестартирате процеса на генериране на библиотеката. Системата проверява цялото съдържание, открива нови файлове и включва тези драйвери в базата данни.
Препоръчително е да поддържате логическа структура на подпапките по производител, модел или тип устройство (например: /Dell/Laptops, /HP/Desktops, /Network_Drivers и др.). Въпреки че инструментът HII може да сканира всичко без тази организация, той ще ви спести много главоболия при извършване на поддръжка.
Използване на хранилището в поредици от задачи за изображения
След като хранилището е стартирано и работи, най-често срещаната практика е да го интегрирате във вашата последователности от задачи за внедряване на изображенияТова гарантира, че при инсталиране на операционна система от нулата, подходящите драйвери се прилагат автоматично въз основа на открития хардуер.
В много среди се използва една единствена последователност от изображения за всички модели оборудване и се добавят няколко стъпки от този тип. „разполагане на пакет с драйвери“Всяка стъпка е свързана с WMI заявка или филтър за хардуерен модел, който гарантира, че пакетът се изпълнява само на подходящите компютри.
Например, можете да имате стъпка, която се изпълнява само ако WMI заявката върне, че компютърът е конкретен модел лаптопЗа различно семейство настолни компютри от друг производител се предприема различна стъпка и т.н. По този начин една и съща последователност от задачи обхваща много хетерогенен набор от устройства, без да е необходимо клониране и поддържане на множество работни процеси.
Тези стъпки за внедряване на драйвери разчитат на централното хранилище и в базата данни с драйвериПоследователността на задачите определя кой пакет трябва да бъде инсталиран, а инструментът за осигуряване, поддържан от HII или еквивалентна система, локализира необходимите драйвери в хранилището и ги изтегля или чрез UNC, или чрез URL, в зависимост от контекста.
Хранилища за драйвери, за да могат потребителите да актуализират системата си
Често задаван въпрос в много ИТ екипи е дали е възможно да се подготви последователност от задачи, състояща се единствено от стъпки от „разполагане на пакет с драйвери“ и да го покажете на портал от типа на Софтуерен център, така че потребителят да може сам да стартира актуализацията на драйвера, когато е необходимо.
Технически е възможно да се настрои нещо подобно, стига вашият инструмент за управление да го позволява. стартиране на поредици от задачи при поискване и контролирайте необходимите разрешения. Работният процес ще се състои от създаване на последователност без стъпки за инсталиране или форматиране на операционната система, а само стъпки за актуализиране на драйвери, базирани на пакети от вашето хранилище.
Тези стъпки ще продължат да използват същия механизъм на WMI заявки или филтри за моделитака че всеки екип да изпълнява само пакетите, които действително са от значение за него. Голямата разлика е, че вместо да се задейства последователността от централната конзола като част от проект за изображение, тя ще бъде публикувана в един вид „каталог на приложения“, който потребителят да изпълнява, когато забележи проблеми с драйверите или когато е планирана кампания за актуализация.
Въпреки това, аспектите, свързани със стабилността и поддръжката, трябва да се вземат предвид: актуализиране на драйвери на новоинсталирано оборудване в сравнение с такова, което се произвежда от месециПрепоръчително е да тествате обстойно тези пакети драйвери и евентуално да запазите този тип последователност за напреднали потребители или специфични случаи, когато контролираната актуализация е добре оправдана.
Разширено управление на хранилища и конфигурация на ниско ниво
В допълнение към хранилището за драйвери, свързано с инструмента за осигуряване, в някои продукти играе роля и друг критичен компонент: вътрешни хранилища за данни или резервни копия използвани от ядра или централни сървъри. Конфигурацията им може да бъде обусловена чрез системния регистър на Windows, което добавя допълнителен слой сложност.
В среди, където се използват решения за възстановяване или защита (с основни услуги, които управляват вътрешни хранилища), съществуват официални процедури за Спрете услугата безопасно, преди да промените настройките на хранилищетоТова включва паузиране на репликацията между възлите, паузиране на защитата на всички машини и гарантиране, че няма текущи процеси, които зависят от тази услуга.
След като тези операции бъдат поставени на пауза от конзолата (обикновено от раздел като „Защитени машини“Чрез избиране на всички компютри и избиране на действия като „Пауза на защитата“, „Пауза на репликацията“ и „Отмяна на всички операции“), основната услуга в операционната система се спира, идентифицирайки я в конзолата за услуги на Windows.
В някои много специфични сценарии е необходимо да се промени конфигурация на вътрешното хранилище чрез системния регистърЗа да направите това, отворете редактора на системния регистър (regedit) от диалоговия прозорец за изпълнение и отидете до конкретни пътища, като например HKLM\Software\AppRecovery\Core\Repositories\FileConfiguration\Specification.
В този клон може да има запис като „Политика за разпределение“Стойността на тази стойност определя определени поведения, свързани с разпределението на ресурсите на хранилището. Промяната на тази стойност (например, задаването ѝ на 1) може да бъде част от процедура за разширена настройка, стига да знаете точно какво правите и да следвате официално ръководство.
Важно е да се помни, че намесата в системния регистър на Windows може да има сериозни последици. да направите вашата система или хранилища неизползваемиПоради това производителите обикновено ясно заявяват, че не предоставят поддръжка за проблеми, произтичащи от неправилни промени в системния регистър, и силно препоръчват да създадете резервно копие, преди да правите каквито и да е промени. Microsoft има специфична документация, обясняваща какво представлява системният регистър, как е структуриран и как да се извършват правилни архивирания и възстановявания.
Множество хранилища за код и драйвери във Visual Studio
При управлението на драйвери и свързани инструменти, все по-често екипите за разработка и системи работят заедно, използвайки инструменти за програмиране и IDEВ този контекст, Visual Studio 2022 и по-нови версии имат една много интересна функция: съвместимост с множество активни Git хранилища едновременноТова е много полезно, когато кодът и инструментите за внедряване са разпръснати в различни проекти.
Започвайки с версия 17.4, Visual Studio ви позволява да имате до 25 хранилища, активни едновременно в един и същ случай. Това означава, че можете да отворите сложно решение, което включва frontend проекти, API, бази данни, документация, помощни библиотеки и скриптове за внедряване, всяко в собствено Git хранилище, и да работите с всички тях едновременно, без да е необходимо да отваряте множество IDE прозорци.
Управлението на акаунти е предназначено и за среди с множество хранилища: ако работите с повече от един GitHub акаунтМожете лесно да превключвате между тях. Visual Studio актуализира конфигурацията на Git за всяко хранилище, за да запомни кой акаунт се използва за всяко от тях, което е много полезно, ако комбинирате корпоративни и лични хранилища или си сътрудничите с различни организации.
Управление на клонове и промени в множество хранилища
Интеграцията на множество хранилища във Visual Studio се отразява във всички интегрирани Git инструменти, особено в прозореца на „Промени в Git“ и в един от „Git хранилище“Можете да управлявате сценарии, при които едно и също решение обхваща множество хранилища, по същия начин, както бихте го направили само с едно, но с по-голям контрол и видимост.
Visual Studio ви позволява да създавате клонове едновременно в няколко свързани хранилища чрез разширен диалогов прозорец за създаване на клонове. Ако например подготвяте нова версия на инструмента за внедряване на драйвери, която засяга както backend кода, така и скриптовете за автоматизация, можете да създадете съответните клонове във всички хранилища едновременно.
Докато правите промени във всеки проект, прозорецът „Промени в Git“ ще ги актуализира. разделени по хранилищеКато е ясно кои файлове на кого принадлежат, можете да индексирате и commit-вате тези промени по обичайния начин, но с по-организиран изглед на това в кое хранилище работите във всеки един момент.
Селекторите на клонове, както в лентата на състоянието, така и в прозореца за промени, ви позволяват да бързо превключване на клонове по хранилищеОсвен това, от контекстното меню на всеки клон можете да извършвате често срещани операции по работния процес, като например сливане, пребазиране, преименуване, изтриване или сравняване на клонове, дори в сценарии с множество отворени хранилища.
Мрежови операции и конфигурация на Git хранилище
Когато е време да синхронизирате промените в кода си с отдалечените устройства, Visual Studio предлага диалогов прозорец мрежови операции (push, fetch, pull) което ви помага точно да изберете целевия клон и реда, в който публикувате промените, което е особено важно, когато работите с множество хранилища едновременно.
В този диалог можете да упражнявате по-голям контрол върху операции като заснемане (извличане) и извличане (дърпане)Това ви позволява да решите кои клонове на кои хранилища искате да актуализирате във всеки един момент. Това е особено полезно, когато не искате да преместите всички хранилища заедно, а само тези, които са готови за синхронизиране с дистанционното управление.
На ниво конфигурация, Visual Studio ви позволява да настройвате специфични за хранилището опции от панела. „Инструменти > Опции“В секцията Source Control > Git Settings > Git Repository Settings можете например да укажете дали искате автоматично да изтривате файлове. остарели отдалечени клонове по време на извличане в това конкретно хранилище.
Ако е необходимо да приложите определени правила към всички хранилища, които управлявате, можете да използвате Глобална конфигурация на Git от един и същ панел. По този начин поддържате последователен набор от настройки (като потребителско име, имейл или поведение по подразбиране за определени операции) и същевременно имате възможност да персонализирате поведението на конкретни хранилища в зависимост от проекта.
Зареждане и активиране на множество хранилища от решения и папки
Има два основни подхода за работа с множество хранилища във Visual Studio, в зависимост от това как сте организирали кода си, драйверите и инструментите за внедряване: чрез споделено решение (.sln) или чрез отваряне на папка, която съдържа няколко директории на хранилище.
В случая на решения, типичният процес се състои в отваряне на решение, което вече има инициализирано хранилище, и след това, добавете съществуващи проекти, които принадлежат на други хранилищаЗа да направите това, щракнете с десния бутон върху решението в Solution Explorer, изберете „Add > Existing Project“ и изберете .csproj файла на проекта, който има собствено инициализирано Git хранилище.
След като проектът бъде добавен, Visual Studio автоматично открива, че второ хранилище и го активира, така че всички хранилища, свързани с решението, да станат видими и управляеми от прозорците на Git. Ако създадете нов проект в решение, което вече съдържа други хранилища, ще трябва да го инициализирате с `git init`, така че той също да стане част от управлението на множество хранилища.
Другият вариант е да работите „по папка“. Ако вашите хранилища са относително независими и не е необходимо да са в едно и също решение, можете да ги организирате като поддиректории в рамките на обща главна папкаОт началния екран на Visual Studio изберете опцията „Отваряне на локална папка“ и изберете тази главна папка.
Visual Studio ще открие всяка подпапка, която съдържа инициализирано Git хранилище и ще ги активира всички наведнъжОттам прозорците „Git Changes“ и „Git Repository“ ще проследяват модификациите по хранилище, предоставяйки ви унифициран, но отделен изглед, идеален за управление на свързани инструменти (напр. скриптове за автоматизация на драйвери, помощни програми за администриране, модули за уеб управление и др.).
В крайна сметка, настройването и поддържането на локално хранилище за драйвери, интегрирането му във вашите последователности за внедряване и координирането му с хранилища за код в инструменти като Visual Studio ви позволява да да се автоматизира осигуряването и актуализациите на оборудването във възможно най-голяма степен.
Комбинирането на добра организация на контролерите, сигурни процедури за настройване на вътрешни хранилища и организирано управление на Git клонове и хранилища превръща поддръжката на много свързани устройства и проекти от пъзел в повтаряем, проследим и много по-спокоен процес. Споделете това ръководство и повече потребители ще научат по темата..