Obszar nazw Microsoft.Policies.WindowsStore jest już zdefiniowany…

23 listopada 2015 at 13:27

Niechlubna seria związana z pomyłkami, niedopatrzeniami, niedoróbkami, błędnym tłumaczeniem oraz innymi błędami w definicjach ADMX/ADML, które zostały udostępnione wraz z Windowsem 10 niestety trwa w najlepsze… Pierwszy problem: http://mkrzanowicz.pl/?p=491 Drugi problem: http://mkrzanowicz.pl/?p=328 Trzeci problem: http://mkrzanowicz.pl/?p=479 Więc być może do czterech razy sztuka? Oby… Tym razem kolejny problem dotyczy definicji Office’a: https://www.microsoft.com/en-us/download/details.aspx?id=49030 Po ich wgraniu na SYSVOL pojawia się znajomy (ale inny) błąd: Co zrobić? Rozwiązanie jak zwykle jest podobne, z tym że dotyczy innej definicji. Tym razem padło na „parę” WindowsStore.admx/WindowsStore.adml oraz WinStoreUI.admx/WinStoreUI.adml Czyli sprowadza się do usunięcia plików: 1. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\WinStoreUI.admx 2. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\pl-pl\WinStoreUI.adml 3.  \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\en-US\WinStoreUI.adml Zmian nazw plików: 4. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\WindowsStore.admx na \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\WinStoreUI.admx 5. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\pl-pl\WindowsStore.amdl na \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\pl-pl\WinStoreUI.adml 6. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\en-US\WindowsStore.amdl na \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\en-US\WinStoreUI.adml   Rozpropagowania zmian w AD:

i cieszenia się, że znowu (na jakiś czas, do kolejnej wersji definicji… 😉 ) wszystko działa poprawnie bez irytujących komunikatów o błędach.

Nie można odnaleźć zasobu $(string.SUPPORTED_Vista_through_Win7) …

3 listopada 2015 at 12:47

Od czasu wprowadzenia Windowsa 10 do środowisk produkcyjnych aż po dzień dzisiejszy widoczne są niedoróbki związane z development’em tego systemu operacyjnego czy jego poszczególnych komponentów a także wspieralności i kompatybilności z wcześniejszymi wersjami systemów. Tym razem kolejny problem z szablonami zasad grup (pierwszy opisywany: http://mkrzanowicz.pl/?p=328 ) Oczywiście można te błędy zignorować i klikać za każdym razem „OK” ale nie jest to zbyt profesjonalne. Dzisiaj na tapetę bierzemy kolejny błąd tj: Źródło błędów jest podobne jak w poprzednim artykule o błędach, natomiast poprzednie rozwiązanie w tym wypadku nie zadziała… Co robić? Jak żyć? Ano trzeba poprawić developerów/tłumaczy Microsoftu i dopisać jedną linijkę do pliku z definicjami językowymi (adml). Co prawda błąd ewidentnie odwołuje się do definicji ADMX, konkretnie do linijki, która wygląda tak” „          <definition name=”SUPPORTED_Vista_through_Win7″ displayName=”$(string.SUPPORTED_Vista_through_Win7)”>„ Ale w rzeczywistości problemem jest brak wpisu w definicji językowej, która przetłumaczy czym jest „SUPPORTED_Vista_through_Win7„. Poprawmy więc developerów/tłumaczy Należy przejść do edycji pliku znajdującego się na SYSVOL’u w ścieżce: „\\Nazwa_Domeny\SYSVOL\Nazwa_Domeny\Policies\PolicyDefinitions\pl-pl\PreviousVersions.adml” I dopisać: „<string id=”SUPPORTED_Vista_through_Win7″>Vista i 7</string>” Np. w tym miejscu przed końcem pliku: Oczywiście zreplikować dane na wszystkie kontrolery domeny i cieszyć się brakiem denerwujących błędów 😉

Błąd ADMX „‚Microsoft.Policies.Sensors.WindowsLocationProvider’ is already defined”

17 września 2015 at 13:17

Wraz z nadejściem Windows’a 10 (długo potem…) nadeszły szablony ADMX do zarządzania ustawieniami systemu z wykorzystaniem GPO. Zmienił się nieco sposób dystrybucji do SYSVOL’a, który teraz wymaga zainstalowania pakietu na stacji bądź serwerze i wyciągnięcie szablonów z dedykowanego folderu – to wcale nie jest ułatwieniem – ale nie w tym rzecz. Niestety po nadpisaniu starszych ADMX’ów, przy próbie edycji dowolnego GPO oczom ukazują się błędy: W sumie nic istotnego i błąd można śmiało zignorować klikając OK, natomiast pedantyczny i purystyczny admin takiego widoku nie zniesie… Rozwiązaniem są trzy proste kroki 1. Usunięcie plików „LocationProviderADM.admx” oraz „LocationProviderADM.adml” z SYSVOL’a 2. Zmiana nazwy pliku definicji z „Microsoft-Windows-Geolocation-WLPAdm.admx” na „LocationProviderADM.admx” 3. Zmiana nazw plików definicji języków z „Rename Microsoft-Windows-Geolocation-WLPAdm.adml” na „LocationProviderADM.adml”

Nie można odnaleźć zasobu $(string. * ), do którego odwołuje się atrybut displayName. Plik *.admx

27 kwietnia 2015 at 16:50

Kolejny dzień – kolejne problemy do rozwiązania Tym razem problemy z GPO, a ściślej mówiąc z widocznością ustawień i możliwością ich edycji. Podczas próby podglądu czy edycji ustawień GPO użytkownicy otrzymywali groźnie wyglądające błędy typu: Na szczęście sytuacja nie była zła, bo zasady grup działały, aplikowały zmiany itd. Co ciekawe na kontrolerach domeny problem nie występował – tam można było normalnie przeglądać i edytować ustawienia wszystkich GPO: Gdzie jest więc „pies pogrzebany”? W tym środowisko funkcjonuje Central Store for Group Policy Admin Templates, więc nie była to kwestia poszczególnego kontrolera domeny. Zostały również sprawdzone uprawnienia użytkownika per konkretne GPO i plik ADMX z definicją – wszystko było OK… Podmienione zostały nawet wybrane pliki ADMX – bez efektu… Sprawa niby nie pilna, bo zasadniczy mechanizm GPO działał prawidłowo, natomiast mocno irytująca dla operatorów GPO. Test na spostrzegawczość – czym jeszcze różnią się zrzut działający od tego, który nie działał jak powinien? Bingo – językiem A więc mimo opisu wskazującego na uszkodzenie plików ADMX – w istocie problem stanowiły pliki ADML odpowiadające za „reprezentację” zasad w danym języku. Prawdopodobnie ktoś podczas aktualizacji folderu „PolicyDefinitions” na SYSVOL’u zapomniał o wgraniu aktualnych plików ADML lub podczas odtwarzania/przywracania plików rozjechały się ich tłumaczenia. Jak można […]

Stacja nie przetwarza poprawnie GPO

9 lutego 2015 at 13:04

W przypadku, gdy stacja robocza z uporem maniaka nie chce przetwarzać w poprawny sposób obiektów zasad grup (GPO) – mimo, że wszystkie znaki na niebie i ziemi wskazują na to, że stacja powinna GPO przetworzyć (poprawna jednostka, uprawnienia, WMi itd..) OK. Zaczynamy od samej stacji roboczej: 1. uruchamiamy cmd 2. wykonujemy polecenie:

I otrzymujemy piękny błąd: Oczywiście można klikać linki i szukać rozwiązania w raportach ale… zależy nam na czasie, więc: Przechodzimy do katalogu:C:\ProgramData\Microsoft\Group Policy\History\ (Pod warunkiem, że dysk ‚C:\’ jest dyskiem systemowym ) Usuwamy całą zawartość ww. katalogu. Wykonujemy kolejny raz polecenie:

I wszystko działa jak należy: Świat uratowany

© Marcin Krzanowicz