Nesen tika ziņots par jaunu ierīču uzstādīšanu Windows ADK uz Windows 10 v 1703 un Windows Server 2016, izmantojot lietotājus, kuri darbojas ar drošu sāknēšanas funkciju. Kaut arī galvenais problēmas cēlonis joprojām nebija identificēts, tika konstatēts, ka galvenais iemesls tam bija nepareizi parakstīts WIMMOUNT draiveris, kas iekļauts ADK. Tas tika uztverts ar diviem ievērojamiem simptomiem
- Palaidējs no Programmas saderības palīga ADK instalēšanas laikā.
- Ierīce neizveido WIMs pēc ADK 1703. Tas izpaužas kā MDT šādā veidā:
Windows ADK operētājsistēmai Windows 10 v1703 un tā risinājumiem
Par laimi, Microsoft ir izstrādājis risinājumu. Tas ir publicējis atjauninātu draiveri, kas ir parakstīts. Ja nezināt, vairāki faili, kas iekļauti Windows novērtēšanas un ieviešanas komplekta, tostarp arī wimount.sys, funkciju Izvietošanas rīki, tiek digitāli parakstīti ar vecāku sertifikātu. Tādējādi šie faili tiek uzskatīti par labiem kā nesankcionēti jaunākām operētājsistēmām, un tāpēc bloķē vai pilnībā aptur, kad SecureBoot ir iespējots. Tieši šī iemesla dēļ Microsoft iesaka palaist "Secure Boot", nevis izslēgt to.
Otrkārt, draiveri wimount.sys lieto DISM, lai veiktu montāžu, kas tiek izmantota Configuration Manager vietnes serverī, lai izveidotu un apkalpotu boot attēlus, turklāt, lai veiktu bezsaistes apkalpošanas operācijas OS Attēlu un OS jaunināšanas paketēs.
Emuāra Microsoft Technet ziņā ir norādīts, ka klientiem, kas izmanto Configuration Manager pašreizējo filiāles versiju 1702 un izvieto Windows 10 versiju 1703, jāizmēģina šādi risinājumi.
Microsoft galvenais ieteikums, lai izlauztu klientus, kuri vēlas instalēt Windows 10 versiju 1703, izmantojot tradicionālās OS ieviešanas metodes, ir izmantot Windows ADK versiju 1607 versijai, lai strādātu ar operētājsistēmu Windows 10, versijas 1703 sāknēšanas un OS attēliem. Šī priekšu saderība tiek atbalstīta pamata attēlveidošanas darbībām (uztveršana / piemērošana).
Īpaši vērts pieminēt, ka Windows 10 jaunināšanas vietne un Windows 10 apkalpošana neizmanto Windows ADK komponentus. Rezultātā šie scenāriji neietekmē šo problēmu.
Kā alternatīva iepriekš minētajam, Windows lietotāji var izvēlēties atspējot SecureBoot. Lai gan tehniski ir izvēles iespēja, Microsoft mudina to neizmantot ražošanas vidē, jo tas palielina iespējamo risku serverim.
Microsoft ir atlaidis arī šo problēmu. Lai iegūtu papildinformāciju par šo tēmu, apmeklējiet TechNet emuāru.
