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 […]

Krytyczna podatność Active Directory

16 lutego 2015 at 12:01

Miniony tydzień oferował w wykryte luki bezpieczeństwa systemów Windows a także poprawki mające załatać te podatności. Jedną z najistotniejszych jest możliwość podszycia się pod zasoby udostępniane na kontrolerach domeny i wykonanie w ten sposób dowolnego kodu w kontekście konta systemu… Zostały udostępnione dwie poprawki w ramach biuletynu zabezpieczeń: MS15-011 Konkretnie są to poprawki: kb3004375 oraz kb3000483. Ich instalacja zabezpiecza klientów przed możliwością wykonania ataku, ale mimo wszystko nie zapewnia bezpieczeństwa całej domeny, bo nigdy nie ma pewności, że ktoś nie wyciągnie „gołego” lub nieaktualizowanego rok czasu systemu z szafy i nie wepnie się nim w naszą sieć z Active Directory. Aby temu zaradzi i podnieść poziom bezpieczeństwa należy wykonać następujące akcje: 1. Zainstalować ww. krytyczne poprawki bezpieczeństwa na kontrolerach domeny (wymagany restart serwerów) 2. Włączyć wzajemne uwierzytelnianie dla zasobów udostępnianych na kontrolerach domeny. 3. Włączyć wymaganie integralności SMB Dla domen, w których pracują tylko serwery Windows Server 2012 i wyższe oraz klienci Windows 8 i wyżsi – można dodatkowo włączyć wymaganie prywatności razem z szyfrowaniem żądań ścieżek SMB.   Plan działania wygląda w miarę prosto, ale jak zwykle gdzieś leży haczyk – a właściwie dwa haczyki. Pierwszym z nich jest GPO. Teoretycznie wystarczy dodać ustawienie w GPO: W gałęzi: Computer […]

© Marcin Krzanowicz