Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
září 08
Všechny linky na Office365 a Azure co jste kdy potřebovali

Totální mejhem. Tak bych asi charakterizoval URL linky do různých služeb Office365. Tady je přehled, co jsem potřeboval, nebo zjistil a podobně. V následující tabulce jsou velice podstatné HTTPS prefixy, protože v mnoha případech nefungují. Pánové totiž dělají redirect jen na portu 80. Zřejmě proto, že to hostují na nějakém CDP a tím pádem tam nechtějí mít svůj certifikát na cizím webu. Když je na začátku X, tak ten odkaz nefunguje. Některé linky jsou jen pro ukázku, takže nejsou klikatelné.

Což je mimochodem případ i autodiscover, což pěkně zpomaluje, případně totálně kriplí Outlook., pokud nemáte hybridní scénář, kde je autodiscover u vás na onpremisu.

Link Co Poznámky
https://manage.windowsazure.com správa azůru  
https://signup.live.com založení Microsoft Account dříve Windows Live Id, neboli .NET Passport
https://login.live.com/logout.srf odhlášení Microsoft Account dříve Windows Live Id, neboli .NET Passport
http://office.microsoft.com/en-us objednávka trial verze Office365 Enterprise E3 kliknout úplně dole na slovo Enterprise
samozřejmě v angličtině, číst to česky nejde
http://office.microsoft.com/en-us/business/office-365-enterprise-e3-business-software-FX103030346.aspx objednávka trial verze Office365 Enterprise E3 přesný link bez ručního klikání, jenže kdo ví, jak dlouho vydrží funkční
https://portal.office.com správa a výchozí rozcestník Office365 tohle je správně na HTTPS. Přihlášení pouze organization account nebo ADFS.
http://portal.office365.com správa a výchozí rozcestník Office365 nelze použít s HTTPS, špatně uděláné přesměrování
X https://portal.office365.com - nefunguje HTTPS
https://login.microsoftonline.com správa a výchozí rozcestník Office365  stejné jako předchozí dva odkazy. Přihlašování pouze organization account nebo ADFS
https://login.microsoftonline.com/logout.srf odhlášení z Organization Account  
https://outlook.office365.com OWA stejně ale skončíte na doméně outlook.com :-)
http://outlook.office365.com OWA  
X https://outlook.office.com - nefunguje
X http://outlook.office.com - nefunguje
http://mail.office365.com OWA  
X https://mail.office365.com - podivně nefunguje HTTPS
X http://mail.office.com - nefunguje
X https://mail.office.com - nefunguje
http://outlook.office365.com/gopas.cz
http://login.microsoftonline.com/gopas.cz
přesměrování na správnou přihlašovací obrazovku pro vaši doménu pozor! Opět nefunguje s HTTPS, protože to přesměrování dělá CDP (content delivery provider). Tady vás to přehodí buď na vaši vnitřní AD FS stránku (buď FBA, nebo WIA - windows integrated authentication), nebo na MS vlastní při použití Office365 organization account.
http://technet.microsoft.com/library/office-365-system-requirements.aspx požadavky na Office365 kdyby to nefungovalo, tak googlujte: "Office 365 System Requirements"
https://outlook.office365.com/powershell-liveid/ -ConnectionURI pro vzdálený PowerShell do Exchange Online připojíte se nějak takto:
$session = student@gopas.onmicrosoft.com | % { New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential (Get-Credential $_) -Authentication Basic -AllowRedirection }
Import-PSSession $session
https://ps.outlook.com/powershell -ConnectionURI pro vzdálený PowerShell do Exchange Online to stejné jako v přechozím případě, jenom mi někdy to minulé nefungovalo. Asi v případě jiného plánu, než Enterprise?
autodiscover.outlook.com autodiscover CNAME  
sipdir.online.lync.com sip. Lync CNAME a _sip SRV  
webdir.online.lync.com lyncdiscover. Lync CNAME  
sipfed.online.lync.com _sipfederationtls Lync SRV  
http://testconnectivity.microsoft.com online testování konektivity  
http://autodiscover.outlook.com/autodiscover/autodiscover.xml testovací URL na autodiscover všimněte si, že HTTPS opět nefunguje, což potom děsně zpomaluje Outlook, nebo vyskakují chybové hlášky o špatných certifikátech úplně úchylných webů. Ano, tahle stránka potřebuje ověření, buď organization account, nebo vaše vnitřní AD FS.
http://technet.microsoft.com/library/hh373144.aspx seznam IP adres a portů kdyby to nefungovalo, tak googlujte: "Office 365 URLs and IP address ranges"
http://office.microsoft.com/en-us/products/office-365-roadmap-FX104343353.aspx přehled novinek a jejich plánů do budoucnosti kdyby to nefungovalo, tak googlujte: "Office 365 roadmap"
http://www.microsoft.com/en-us/download/details.aspx?id=19011 kalkulátor spotřeby pro Lync kdyby to nefungovalo, tak googlovat: "Lync 2010 and 2013 Bandwidth Calculator"
http://gallery.technet.microsoft.com/Exchange-Client-Network-8af1bf00 kalkulátor nároků pro Exchange Online googlovat: "Exchange Client Network Bandwidth Calculator"
http://mxtoolbox.com ne-Microsoft kontrola MX záznamů a RBL  
https://www.ssllabs.com/ssltest ne-Microsoft kontrola SSL a TLS certifikátů a spojení  
http://technet.microsoft.com/en-us/library/jj151815.aspx Windows Azure PowerShell linky ke stažení aktuálních verzí Windows Azure PowerShellu a sign-in asistenta. Potřebujete oba dva.
https://adfs.gopas.cz/federationmetadata/2007-06/federationmetadata.xml AD FS metadata anonymní přístup (bez nutnosti ověřit), vrátí celé XML popisující daný AD FS server včetně jeho podepisovacího certifikátu ve formě Base-64
https://adfs.gopas.cz/adfs/ls/idpinitiatedsignon.htm test AD FS přihlášení přihlašovací stránka FBA (forms-based authentication) kterou lze ověřit, že AD FS opravdu ověřuje uživatele
https://adfs.gopas.cz/adfs/ls/?wa=wsignout1.0 odhlášení z AD FS zruší cookie pro AD FS. nezruší to tedy cookie pro online službu. Navíc, pokud jste se přihlašovali pomocí WIA (windows integrated authentication), tak odhlašování nemá v podstatě smysl, protože to proběhne jako SSO (single-sign-on) znovu automaticky když se vrátíte na předchozí stránku.
https://adfs.gopas.cz/adfs/ls/?wa=wsignout1.0&wreply=https://www.google.cz odhlášení z AD FS s přesměrováním  
září 05
WiFi hotspot na Windows

Potřeboval jsem si udělat z Windows WiFi hotspot pro mobil. Prostě když mám připojen notebook do rychlého Ethernetu a není k tomu WiFi připojení, tak je škoda to nevyužít i na mobilu. Prostě na mobilech to normálně jde jednoduše (na mém iPhone se to jmenuje personal hotspot). Jenže jak jsem nezjistil, že by to šlo moc jednoduše na Windows. Popravdě nechápu.

Takže jsem gůgloval a zde je výsledek. Musíte si nastavit a povolit tzv. hosted network pomocí NETSH. A potom zapnout Internet Connection Sharing (ICS) na té skutečné síťovce, která je opravdu připojena do internetu. A ještě udělat díru do firewallu pro DHCP a DNS. To je hodně kroků, které se mi nechtějí dělat opakovaně. Tak jsem si na to udělal PowerShell skript:

$physicalIF = 'LAN'
$hotspotSSID = 'ondass'
$hotspotPwd = 'ondrovoUltraHeslo77'


netsh wlan set hostednetwork mode=allow ssid=$hotspotSSID key=$hotspotPwd
netsh wlan start hostednetwork


Set-Service -ServiceName SharedAccess -StartupType Disabled
Start-Service SharedAccess


regsvr32 /s hnetcfg.dll

$ics = New-Object -ComObject HNetCfg.HNetShare
$allNics = $ics.EnumEveryConnection | % { $ics.NetConnectionProps.Invoke($_) }

$publicNicCfg = $allNics | ? { $_.Name -eq $physicalIF }
echo ($publicNicCfg | Out-String)

$privateNicCfg = $allNics | ? { $_.DeviceName -eq 'Microsoft Hosted Network Virtual Adapter' }
echo ($privateNicCfg | Out-String)

$ics.EnumEveryConnection | % { $ics.INetSharingConfigurationForINetConnection.Invoke($publicNic).DisableSharing() }

$publicNic = $ics.EnumEveryConnection | % { if ($ics.NetConnectionProps.Invoke($_).Name -eq $physicalIF) { $_ } }
$publicNicICS = $ics.INetSharingConfigurationForINetConnection.Invoke($publicNic)
echo ($publicNicICS | Out-String)
$publicNicICS.EnableSharing(0)

$privateNic = $ics.EnumEveryConnection | % { if ($ics.NetConnectionProps.Invoke($_).DeviceName -eq 'Microsoft Hosted Network Virtual Adapter') { $_ } }
$privateNicICS = $ics.INetSharingConfigurationForINetConnection.Invoke($privateNic)
echo ($privateNicICS | Out-String)
$privateNicICS.EnableSharing(1)


netsh advfirewall firewall add rule name="HotSpot DHCP In" dir=in localport=67 protocol=udp profile=private action=allow
netsh advfirewall firewall add rule name="HotSpot DNS In" dir=in localport=53 protocol=udp profile=private action=allow
září 03
Jak namapovat Office365 ImmutableID na uživatele v Active Directory

Scénář - máte Office365 a synchronizujete účty (nebo jste to dříve udělali alespoň jednou) z vaší on-premisses Active Directory (AD) pomocí nástroje DirSync (což je ve skutečnosti normální FIM) do Azure Active Directory (AAD), nad kterou celý ten Office365 vlastně pracuje.

DirSync si musí pamatovat vazbu mezi objektem v Active Directory a objektem v Azure AAD. Pamatuje si to pomocí tří atributů - sourceAnchor, cloudAnchor a ImmutableID. Atributy sourceAnchor a cloudAnchor jsou uvnitř FIMu a obsahují hodnotu z atributu objectGUID v AD a ObjectID v AAD.

Jak jistě víte, atribut objectGUID se v AD nemění, ani když daný objekt migrujete mezi doménami. Stejně tak ObjectID atribut v Azure AD, se nemění. Hodnotu ObjectID z AAD můžete zjistit pomocí Get-MsolUser. Hodnotu objectGUID zjistíte z on-premisses AD pomocí Get-ADUser.

Pokud synchronizujete účty z AD do AAD pomocí DirSync, ten nástroj zapisuje do Azure AD hodnotu z objectGUID do ImmutableID. Aby se ty dva objekty daly spárovat kdykoliv později. Jenže ImmutableID obsahuje Base64 zakódovanou binární hodnout z atributu objectGUID.

ImmutableId vypadá potom nějak takto: TH+F1opA4kua555eKYcQBQ==

Nastupuje tedy kamarád PowerShell:

$msolUser = Get-MsolUser -User kamil@gopas.cz

$immutableIdLdapSearchString = '\' + [BitConverter]::ToString([Convert]::FromBase64String($msolUser.ImmutableId)).Replace('-', '\')

Get-ADUser -LDAPFilter "(objectGUID=$immutableIdLdapSearchString)"

Musíme ho zkonvertovat z Base64 na byte[] a potom znovu do hexa řetězce a eskejpnout všechny bajty.

srpen 31
Záznamy přednášek z konference MVP Open Days v Moskvě 2014

Všechny záznamy z přednášek z konference MVP Open Days v Moskvě z června 2014, jsou k dispozici zde. Je tam i jedna moje :-)

http://www.techdays.ru/series/MVP_DAY_2014

srpen 30
Zajímavé poměry na trhu

Dneska jsem se jenom tak pro zajímavost mrknul na poměry na trhu OS a prohlížečů:

Operační systémy s přehledem vedek Windows 7, Windows XP i nadále 25%

http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0

Prohlížeče na počítačích vede krutě IE, ale jsou zajímavé jeho verze, jak lidi moc neaktualizují:

http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0

Zatímco na mobilech se IE skoro neumístilo :-)

http://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=1

 

Bing opět propadl. Ta parta Indů, která při každém dotazu generuje ručně jeho výsledky, není moc úspěšná, jak se zdá. Asi by to chtělo zvolit jinou strategii :-)

http://www.netmarketshare.com/search-engine-market-share.aspx?qprid=4&qpcustomd=0

Teď mě ještě napadlo - porovnejte používanost Bingu s penetrací operačních systémů Windows a IE prohlížeče. I když je Bing výchozím vyhledávačem, stejně si ho lidi dokážou změnit, když opravdu chtějí.

srpen 23
Skenování IP a MAC adres pomocí PowerShellu

Dneska jenom taková blbůstka - mám virtuálku v Azůru, tak jsem si říkal, že se mrknu, jaké další virtuálky tam jsou. Tak jsem si udělal jednoduchý MAC/IP adresovový skenner v PowerShellu.

$net = '100.79.176' ; (1..254) | % { $ip = $_ ; ping "$net.$ip" -n 1 -w 1000 | out-null ; arp -a | ? { $_ -like "  $net.$ip * ??-??-??-??-??-?? *" } }

V podstatě stačí změnit rozsah IP adres v první proměnné.

Co by si z toho mohl někdo odnést za ponaučení je následující. Bez ohledu na, jestli máte zapnutý firewall (a můžete blokovat všechno), stejně váš počítač bude odpovídat na ARP dotazy. Samozřejmě jsou to broadcasty, takže dostupné jen na stejném segmentu sítě, ale to v případě těchto sdílených prostředí není moc omezující.

srpen 19
Hodnocení konference MVP Open Days v Moskvě z června 2014

V červnu jsem se zúčastnil konference MVP Open Days, která probíhala v Moskvě. Potom ještě následoval výlet do oblasti horní Volhy okolo města Rybinsk. A protože nedávno přišlo vyhodnocení obou těchto přednáškových bloků, nemůžu odolat a musím se tady pochválit. Toto smrdííí:

Session Name Speaker Name Content Score Speaker Score Avg. Score
C403 What would a real hacker do to your Active Directory Ondřej Ševeček 8,7 8,76 8,73
B403 Exchange Design Concepts and Best Practices Oleg Krylov 8,67 8,52 8,59
B306 Publishing Exchange – TMG\UAG Replacement Consideration Oleg Krylov 8,4 8,5 8,45
B401 Lync Server 2013 and Exchange Server 2013 Integration Ilya Rud 8,3 8,52 8,41
A206 SQL Server Analysis Services: Multidimensional vs Tabular Mode? Andrey Korshikov 8,33 8,44 8,39
A305 SQL Server 2014 In-Memory OLTP. Deep Dive for developers Sergey Olontsev 8,33 8,33 8,33
A302 NFC for Windows Phone Developers Catalin Gheorghiu 8,14 8,5 8,32
C206 Using Windows Server 2012 R2 Essentials & Windows Server 2012 R2 Essentials Experience. Scenarios overview Gennadij Chernikov 8,17 8,25 8,21
B102 SQL Server: some tips for the beginners Sergey Olontsev 8,17 8,22 8,2
C205 Front door with locker: Service Manager on IT-duty Anton Gritsenko, Artem Pronichkin 7,88 7,96 7,92
A301 C# 6 new language features Andrew Koryavchenko 7,83 7,61 7,72
C304 Operations Manager - what should you NOT do Alexey Zhuravlev, Artem Pronichkin 7,42 7,9 7,66
A304 Windows Embedded 8(.1) Handheld Catalin Gheorghiu 7,25 8 7,63
C201 What’s New in Hyper-V in Windows Server 2012 R2  Mikhail Komarov 7,74 7,45 7,59
C402 Hyper-V Networking Alexey Zhuravlev, Artem Pronichkin 7,72 7,45 7,59
B305 Windows Azure IaaS - configure, deploy and manage Luka Manojlovic 7,33 7,71 7,52
A203 SQL Injection - are you ready for defense? Andrey Korshikov 6,79 6,84 6,82

 

Session Name Speaker Name Content Score Speaker Score Avg. Score
Building virtual lab environment with PowerShell Ondřej Ševeček 8,75 8,75 8,75
Setting Up Business in the US Dmitry Sotnikov 8,63 8,81 8,72
How to Grow Your Blog Audience and Keep it Engaged Vadim Sterkin 8,52 8,8 8,66
Local Office interaction roundtable Artem Pronichkin, Yulia Belyanina 8,61 8,61 8,61
Demonstrate to Win! Andrey Beshkov 8,57 8,64 8,61
Metrics for SaaS Dmitry Sotnikov 8,33 8,66 8,5
Building up community Bernardin Katić 8,33 8,55 8,44
How to pitch investors Alexander Gornyi 8,4 8,4 8,4
Community technical content Ekaterina Lajintseva 8,18 8,51 8,35
Mysteries of Windows Phone Emulator Catalin Gheorghiu 7,87 8,37 8,12
The art of stage presence Andrey Beshkov 7,85 8,35 8,1
MS et al: SSO challenge on Enterprise landscape Ivan Padabed 8 8,16 8,08
Professional Technical Evangelism Dmitri Nesteruk 7,88 8,17 8,03
Migration of legacy systems to Microsoft Azure Mihail Mateev 7,5 8 7,75
srpen 18
Split DNS a veřejné záznamy uvnitř interního DNS serveru

Kamarád mě požádal, abych se trošku vyjádřil o parádní možnosti, kterou máte, když provozujete tzv. split DNS (někdy split-brain DNS). Tedy skoro každý provozuje split DNS prostředí. Pokud nevíte co to je, určitě to hned poznáte z následujícího obrázku:

Jednoduše - vaše vnitřní doména Active Directory má nějaké vnitřní jméno, běžně tam bývá přípona .local, nebo v jako v mém případě gopas.virtual. K tomu máte uvnitř také DNS server, který obsahuje záznamy pro tato jména ve formě DNS zóny (DNS zone). Vnitřní DNS server je autoritou pro tuto gopas.virtual doménu, která navíc není z internetu přeložitelná.

Někde venku v internetu máte jiný DNS server, který obsahuje zónu pro vaši veřejnou doménu, něco jako v mém příkladu gopas.cz.

Většina A záznamů ve vnitřní zóně gopas.virtual budou privátní IP adresy. Zatímco většina A záznamů ve veřejné zóně gopas.cz budou nejspíš veřejné IP adresy vedoucí na nějaké web servery apod.

Web servery máte buď hostované v internetu, to nás tady nezajímá. Nebo je máte u sebe, například v DMZ, nebo přímo v intranetu v LAN. V našem obrázku jsou tam dokonce dva SharePoint servery, čistě pro příklad.

Oba dva SharePoint mají ve skutečnosti privátní IP adresy a oba ty počítače jsou členem vnitřní gopas.virtual domény. Mají tedy samozřejmě automaticky zaregistrovaná jména (A record) ve vnitřní DNS zóně gopas.virtual. To by vás asi nemělo překvapit.

Problém s přístupem ze vnitř a z venku

Když mají uživatelé přistupovat na ten SharePoint jak z vnitřní sítě (nebo z VPN), tak i přímo z internetu? Lidé to řeší různě.

Šlo by to samozřejmě udělat tak, že SharePoint bude dostupný na více URL, například http://intranet.gopas.virtual (nebo jen krátce http://intranet) a https://intranet.gopas.cz. Tedy dvě různá URL, jedno je čisté HTTP na vnitřní .virtual doméně, zatímco druhé je veřejné a ještě HTTPS. Technicky to samozřejmě vyřešit lze, na to máte na SharePoint technologii Alternate Access Mapping (AAM).

Ale uživatelsky je to nepohodlné a vede to k chaosu jak v hlavách lidí, tak v lincích, které si lidi posílají mailem, nebo které mají uložené v oblíbených poližkách apod. Proč bych to tak dělal? Mám lepší řešení.

Jedno jméno vládne všem

Proč proboha neudělat ten SharePoint rovnou na jednom společném jméně, pěkně veřejném, ideálně tedy https://intranet.gopas.cz. Ze všech směrů to bude přístupné a pořeší se jen technické problémy, zatímco lidi budou fungovat hladce. Plus, až se rozhodně te, že to celé přesunete do Office365, tak si toho nikdo ani nevšimne.

Jenže ty technické problémy...

Ve vnějším DNS, které je autoritou pro veřejnou zónu gopas.cz samozřejmě ten záznam vytvoříte a dáte mu veřejnou IP adresu. Nastane problém s přístupem zevnitř. Vnitřní DNS server toto jméno nezná, bude tedy pouze rekurzivně nechávat překládat název intranet.gopas.cz venku v internetu. Výsledkem bude opět ona veřejná IP adresa.

Ale to se tam nejspíš zevnitř nedostanete, aniž by to váš firewall nějak podporoval (loopback publishing, DNS rewrite apod.). Protože se budete snažit zevnitř dostat přes ten firewall a jeho veřejnou IP adresu zase zpět dovnitř.

Nene, potřebujeme to zařídit tak, aby rovnou vnitřní DNS server znal ono veřejné jméno intranet.gopas.cz a překládal ho rovnou na privátní IP adresu.

Takže dáme do vnitřního DNS serveru celou veřejnou zónu gopas.cz? Uf. Buď tam dáte jen jeden záznam intranet.gopas.cz a všechno ostatní se tím stane automaticky nedostupné (protože vnitřní DNS server bude autoritou pro tuto celou zónu), nebo tam budete muset opsat všechny ostatní záznamy z veřejného DNS serveru.

Samostatná zóna pro jeden jediný záznam?

Právě toto! Ono se to moc neví, ale proč byste nemohli udělat do vnitřního DNS serveru zónu přímo pro jméno intranet.gopas.cz. Do ní už pak jenom vložíte A záznam (neuvedete jméno a bude se to zobrazovat s nápisem (same as parent folder)), který povede na privátní IP adresu SharePoint NLB a je to.

Takto si nezakryjete veřejnou zónu a přitom budete mít maximální flexibilitu.

Chápu, že se to člověkovi na první pohled nezdá, dělat "celou DNS zónu" pro "jeden jediný záznam", ale proč ne? Celá zóna je navíc jeden jediný objekt v Active Directory, A záznam je taky jeden objekt v AD. Takže spotřeba je minimální, výkon netrpí a bezpečnost? Stačí vypnout automatické aktualizace (dynamic update) a není co řešit. Naopak, máte to plně pod kontrolou, to je podle mě spíš výhoda. Ve větších prostředích uvidíte třeba i desítky takových "zóneček".

Nemusíte se starat o zástupce a linky pro víc URL, DNS překlad si řešíte sami na Windows DNS serverech a nemusíte se bavit se síťaři. Pohodička.

srpen 18
Naučte se používat uvozovky, apostrofy, složené závorky a herestring

Jéé, našel jsem článek, co jsem psal před půl rokem a neuveřejnil...

Pokaždé, když tohle ukazuju, setkávám se s poměrně překvapenými výrazy. Možná bude dobře dát tady do kupy, třeba si to někdo přečte.

Řetězce v PowerShellu

Existuje několik možností, jak zadat řetězec v PowerShellu. Můžete to udělat takto:

# pomoci apostrofu (jednoducha uvozovka) - single quote
$text = 'hellow world'

# pomoci normalnich uvozovek - double quotes
$text = "hellow world"

# slozene zavorky - double brackets
$text = { hellow world }

# jednoduche uvozovky (apostrof) a zavinac - at sign
$text = @'
    hello world
'@

# normalni dvojite uvozovky a zavinac - at sign (herestring)
$text = @"
    hello world
"@

Akorát ten výsledek není stejný. Jednoduché uvozovky, neboli apostrof, a normální dvojité úvozovky se nazývají jednoduše string. Pokud tam přidáte ještě zavináč (at sign), tak se to nazývá here string. Složené závorky jsou specialita nazvaná ScriptBlock.

Rozdíl mezi apostrofem a uvozovkami

Cokoliv napíšete do apostrofů (jednoduchých uvozovek) se chápe prostě jako znaky. Uvnitř apostrofů neexistují žádné speciální znaky, kromě jednoho. Co když chcete dovnitř napsat apostrof? Musíte ho jednoduše zdvojit:

$message = 'I would like to say ''hello world'' to the world'

Výsledkem jsou jenom jedny apostrofy. Pokud do apostrofového řetězce vložíte například dvojité úvozovky, nemusíte se ničeho obávat, prostě tam normálně budou:

$message = 'I would like to say "hello world" to the world'

Zato pokud použijete normální uvozovky, má to trošku více možností. Uvnitř dvojitých úvozovek se vyhodnocují escape sekvence a nahrazují se hodnoty proměnných a složitějších výrazů. Podívejte se na následující příklad.

$age = 35
$name = 'Ondrej'

$message = "My name is $name and I am `t`t $age years old"
# result: My name is Ondrej and I am         35 years old

Uvnitř uvozovkového řetězce se vyhodnotí $ (dolar) znak a proměnné $age a $name a nahradí se svou hodnotou. Dále jsem tam rovnou vložil dvakrát escape sekvenci pro speciální znak TAB. Escape sekvence se dělá pomocí znaku zpětného apostrofu (zpětná jednoduchá uvozovka - tick), to je znak co máte úplně nalevo vedle jedničky pod ESC. Jiné speciální escape znaky, které jsou běžně používané jsou `n a `r, tedy konec řádku.

Jak vložíte do uvozovek jiné uvozovky? Musíte to zvnovu escapenout:

$message = "Moje prezdivka je `"ondass`" a me se docela libi"

Jak je vidět, narozdíl od jednoduchých apostrofů, uvnitř nichž jste apostrof museli zdvojit, tady musíte uvozovky escapenout.

Nahrazování proměnných a výrazů uvnitř uvozovek

Jak jsme říkali, řetězce apostrofové samy proměnné nenahrazují. Hodí se to tedy obvykle více jako obecný znak pro ohraničování "čehokoliv". Zatímco uvozovkové řetězcové konstanty mají právě výhodu (někdy to právě není výhoda), že nahrazují proměnné, ale umí nahradit i složitější výrazy.

Samozřejmě pozor na to, že PowerShell musí být schopen poznat, co je jméno proměnné a co není:

$age = 35
$name = 'Ondrej'

$message = "My name is $name and I am $ageYears old"
# result: My name is Ondrej and I am old

Jak je vidět, tady jste neoddělili slovo Years od jména proměnné, takže si PowerShell myslel, že tam chcete vložit hodnotu proměnné $ageYears, která neexistuje.

To se dá vyřešit právě pomocí nahrazování celých výrazů:

$age = 35
$name = 'Ondrej'

$message = "My name is $name and after 20 years, I will be $($age + 20)years old"
# result: My name is Ondrej and after 20 years, I will be 55years old

Jasné? PowerShell vidí uvnitř znak dollaru. Za ním následuje závorka, takže všechno co je uvnitř se nejprve vyhodnotí. V tomto případě nejen jméno proměnné, ale rovnou výpočet. Můžete volat dokonce cmdlety, příkazy a cokoliv, co je prostě PowerShell výraz.

Já osobně nerad používám uvozovky, raději dovnitř vkládám hodnoty pomocí operátoru -f (tedy [String]::Format), protože je to podle mě přehlednější a méně náchylné k chybám, kdy si do uvozovkového řetězce z nepozornosti vložíte dolar jako součást nějakého textu. Typicky heslo Pa$$w0rd :-)

Abyste nemuseli přemýšlet o nahrazování, aneb herestring

Takže jak jsme viděli, v obou formách řetězců se něco nahrazuje. Uvnitř apostrofů sice jenom znak dvojitého apostrofu, ale i tak je to dost. Někdy chcete do řetězce vložit prostě cokoliv. Typickým příkladem je možnost přímo do PowerShellu vložit C# kód, který to umí samo zkompilovat a pustit (jako jsem třeba nedávno použil v případě porovnání na null). Jenže to by byla strašná dřina kontrolovat, co tam musíte opravit, aby to fungovalo správně.

Od toho jsou právě ony herestringy. Prostě dáte navíc zavináč a můžete si psát co chcete. Má to samozřejmě jedno omezení. Here string začíná @', ale tohle musí být poslední znak na řádku. A končí zase opačně apostrof-zavináč, tedy '@, ale tady to musí být vůbec první znak na řádku. Ani mezera před ním nemůže být.

Aby toho nebylo málo, here string můžete udělat i za použití uvozovek, tedy @" a "@. V takovém případě se uvnitř vyhodnocují escape sekvence a proměnné. Na co to tedy je? No na to, že uvnitř můžete používat volně uvozovky, které tím pádem nemusíte escapeovat.

Podivný řetězec typu ScriptBlock

Ono to vypadá divně, když tvrdím, že to je řetězec. Asi to každý chápe jako blok PowerShell kódu, že? Jenže on to je opravdu jen řetězec. Přijme to cokoliv, co tam napíšete. Není to kompilované. Jediné co to dělá, je že to musí mít korektní PowerShell syntaxi. Následující dva příklady jsou podivné, ale od toho je tento článek

# although this is a valid PowerShell script
# when you run it, it will probably fail because you do not have
# a hello program with world parameter available
$validPSstr = ' hello world '
$validPSsb = { hello world }
& $validPSstr
& $validPSsb

# this is an invalid PowerShell code, because if requires
# brackets for its condition
$invalidPDstr = ' if error then fail '
$invalidPD = { if error then fail }

V prvním případě jsem nadefinoval dvakrát ten stejný PowerShell kód, který následně spouštím pomocí operátoru ampersand &. Z pohledu syntaxe je to naprosto v pořádku PowerShell kód. Akorát se podívejte na tu chybu. PowerShell to pochopil tak, že chcete spustit program hello s parametrem world. Což nejspíš neexistuje.

Ve druhém případě vám projde to přiřazení do řetězce, protože tam se nekontroluje syntaxe. Ale právě v případě složených závorek (double bracket) to neprojde. Byť to možná vypadá podobně, klíčové slovo if musí být následováno závorkami, takže tohle není platný PowerShell kód.

Shrnutí

Existují tedy tyto typy řetězců:

  • jednoduché uvozovky (apostrof) - uvnitř se v podstatě nic nenahrazuje, kromě dvojitého apostrofu
  • normální uvozovky (dvojité uvozovky) - uvnitř se nahrazují escape sekvence pomocí znaku zpětného apostrofu (tick) a hodnoty proměnných a obecně výrazů začínajících znakem dollar $.
  • here string - nenahrazuje se nic v případě apostrofového, v případě uvozovkového se uvnitř dá použít bez problémů uvozovka.
  • ScriptBlock - taky je to vlastně jen text. Akorát se mu kontroluje PowerShell syntaxe. Neznamená to, že by příkazy musely existovat. Prostě až se bude spouštět, třeba to klapne :-)

Cvičení na závěr

A zkuste se zamyslet, co asi udělá toto (když to dělá chybu, je to tam tak schválně :-)):

$jmeno = 'Ondrej'
$vek = 35

'Moje jmeno je $jmeno a vek je $vek'

"Moje jmeno je $($jmeno) a vek je $vek"

"Vsechny procesy v retezci $(get-process). To je ale hruuuuza"

"Vsechny procesy v retezci $(get-process svc* | Out-String). Neni to aspon trosku lepsi?"

"Heslo je: Pa$$w0rd"

"Moje jmeno je ''$jmeno''"

'Moje jmeno je `'$jmeno`''

"Co treba ""tohle"""

"Co treba `"jinak`""

'Pujde sem vlozit TAB-`t`t-?'

"Pujde sem vlozit TAB-`t`t-?"

'Jmeno zarovnane doprava {0,20}.' -f $jmeno

"Co tohle jmeno {$jmeno}"

"Co tohle jmeno {$jmeno} a {0}" -f $vek

"Co tohle jmeno `{$jmeno`} a {0}" -f $vek

"Co tohle jmeno {{$jmeno}} a {0}" -f $vek

'Vsechny procesy v retezci {0}. Takto mi to pripadne neprehlednejsi.' -f (get-process svc* | Out-String)

 

srpen 17
Nová parádní vychytávka v PowerShell 3 kterou soudruzi neudělali kompatibilní s PowerShell 2

Dneska jsem narazil na pěknou věc. Obecná teorie tvrdí, že PowerShell 3.0 by měl být zpětně kompatibilní s PowerShell 2.0. Mělo by to znamenat, že co napíšete ve starší verzi, mělo by jet v pořádku v novější verzi. Jak jsem tu už psal, není tomu tak úplně vždycky (což se ostatně dalo čeka). Byť i například obsah proměnné $psVersionTable se snaží tvářit, že všechno by tak být mělo.

Dneska si můžete vyzkoušet příkaz switch a jeho problém při porovnávání konstantních hodnot typu [double], tedy desetinných čísel. Následující kód běží korektně v PowerShell 2.0, zatímco ve verzi 3.0 to vrací jiný výsledek. Zdá se, že PowerShell 3.0 konvertuje ty konstanty na řetězce a tím pádem to potom není schopen korektně porovnat.

PowerShell 2.0 se správným porovnáním:

$double = 5.3
$double.GetType()

switch ($double) {

  5.3 { echo 'prvni' }
  5.4 { echo 'druhy' }
  default { echo 'default' }

}

# result in PowerShell 2.0: prvni

PowerShell 3.0 s jiným výsledkem:

$double = 5.3
$double.GetType()

switch ($double) {

  5.3 { echo 'prvni' }
  5.4 { echo 'druhy' }
  default { echo 'default' }

}

# result in PowerShell 3.0: default

Existuje nějaká forma, která by to v obou verzích jazyka porovnala stejně a korektně? Například takto:

$double = 5.3
$double.GetType()

switch ($double) {

  { $_ -eq 5.3 } { echo 'prvni' ; break ; }
  { $_ -eq 5.4 } { echo 'druhy' ; break ; }
  default { echo 'default' }

}

# result in both PowerShell 2.0 and 3.0: prvni

Musíte si prostě to porovnávání udělat ručně sami pomocí [ScriptBlock], protože jak se zdá, trojka si to konvertuje špatně.

srpen 16
Jak ve skriptu poznáte jestli běžíte ve virtuálním počítači na Hyper-V

Občas něco skriptujete a potřebujete se rozhodovat, jestli běžíte na železe, nebo ve virtuálním počítači. Prozatím to u Hyper-V virtuálních strojů detekuju takto, pomocí WMI třídy Win32_BaseBoard:

$runningInHyperV = gwmi Win32_BaseBoard | % { if (($_.Manufacturer -eq 'Microsoft Corporation') -and ($_.Product -eq 'Virtual Machine')) { $true } else { $false } }

Co jsem googloval, tak se nikdo nedívá na tu hodnotu Product (nebo to stejné v tabulce Win32_ComputerSystem.Model), ale já bych to nepodceňoval. V dnešní době bych očekával, že pomalu začnou věci jako Surface a Nokia hlásit výrobce taky jako Microsoft.

Kdyby to náhodou někdo měl, mohl by sem přikomentovat, jakou má hodnotu v políčku Manufacturer a Product, když si pustí následující skript:

gwmi Win32_BaseBoard | select Manufacturer, Product

 

srpen 15
Snapshot, checkpoint a Hyper-V replikace - tohle není zálohování

Dnes na první pohled možná z trošku jiného soudku. Uvědomte si ale, že spolehlivost a dostupnost jsou základní bezpečnostní požadavky, takže se zase až tak moc od svého obvyklého směru neodchyluju.

Dnes na věčné téma - snapshot (dnes checkpoint) - a na dnes ještě aktuálnější téma Hyper-V replikace.

Bohužel, pořád si někdo myslí, že se jedná o zálohování. Tohle nemá nic společného se zálohováním. V případě Hyper-V replikace (Hyper-V replication) se GUI dokonce tváří, že vytváří tzv. "application consistent recovery point", což je značně matoucí a přitom to taky není zálohování. Špatně to chápat může být smrtící. Když takovou "zálohu" obnovíte, buď si něco nenávratně poškodíte, nebo budete následujících x let řešit opakující se problémky a latentní bugy.

Přehled technologií

Hyper-V nabízí následující technologie, které se nějakým způsobem dotýkají pojmu "zálohování", a které nějak řeší data uložená ve VHD a VHDX souborech.

  • snapshot, neboli checkpoint od Windows 2012 (pouze změna názvu, jinak se nic nemění) - prostě si uděláte v jednom okamžiku snímek virtuálního počítače. Tedy obsahu jeho VHD a VHDX disků a paměti RAM, pokud virtuálka zrovna běží. Mohli bychom to tedy nazývat offline a online snapshot, tedy buď děláte snapshot z vypnutého VM, nebo z běžícího.
  • storage migration - Windows 2012 umí přesunout VHD i VHDX soubory za jízdy virtuálního počítače na jiné úložiště. V případě VHDX souborů můžete přesouvat i na sdílený SMB adresář. Prostě virtuálka jede celou dobu z původního virtuálního hard disku, jakmile je dokopírováno, virtuálka se "pausne", dokopíruje se posledních pár bajtíků a přehodí se to na nové umístění.
  • live migration - virtuální disky zůstávají na stejném místě, jenom se přehodí RAM paměť mezi dvěma stroji, klidně za jízdy virtual machine.
  • Hyper-V replication - Windows 2012 umí kopírovat VHD a VHDX soubory a jejich změny plynule na pozadí na jiný Hyper-V hostitelský stroj. Kopírování neprobíhá úplně plynule, dělá se v balících jednou za 30 sekund, jednou za 5 minut, nebo jednou za 15 minut. Takže na cílovém stroji budete mít několik sekund, nebo minut starou verzi VHD a VHDX souborů. Na co je replikace dobrá se dozvíte na konci.
  • asynchronní mirroring na diskovém poli - relativně levnější hardware technologie, kdy se pole umí samo o sobě kopírovat na jiné diskové pole. Dělá to asynchronně, to znamená, že na druhém poli máte o něco starší stav disků.
  • syncronní mirroring na diskovém poli - ultra mega drahá hardware technologie, kdy se pole miroruje synchronně hned při zápisu každého bloku, takže na druhém poli je v každém okamžiku to stejné.

Storage migration a live migration náz nezajímá, protože v těchto dvou případech se nemůžete vrátit ke staršímu obsahu VHD/VHDX souborů. Zatímco v případě snapshotu/checkpointu a Hyper-V repliky si vrátit starší verzi disků můžete.

A to je ten kámen úrazu.

Obnovit starou verzi VHD nebo VHDX může být smrtící

Už se docela ví, že není zdravé obnovovat jen tak snapshot. Ale ono je to stejné v případě Hyper-V repliky!!! Ani tam to nedělejte. Detaily zde.

Máte řekněme server. Například databázový, nebo Active Directory, nebo Exchange, nebo SMB souborový, nebo cokoliv. Co se asi stane, když ten server vrátíte datově o pár sekund/minut/hodin/dnů zpátky? Mohlo by se zdát na první pohled, že nic podstatného. Prostě přijdete o ta data, která se uložila v té "obnovovací díře" - prostě tam nebudou nějaké soubory, nebo maily, nebo třeba několik uživatelů bude mít zase staré heslo, protože si ho mezitím změnili.

Tak to by až tak nevadilo. S tím se snad počítá, že když obnovuju zálohu, že tam budou jen starší data.

Jenže je jiný problém. Replikace. Všechny tyto technologie obvykle nabízí nějakou formu své vlastní aplikační replikace. V případě Exchange máte dokonce replikací stovky nebo i tisíce. On si totiž každý Outlook ve skutečnosti replikuje obsah svého mailboxu k sobě do offline složek (OST soubor). V případě SMB serveru je tam taky podobná klientská replikace nazvaná offline files.

Obecně bych řekl, že více počítačů nějak sdílí data.

Jak fungují replikace

Představte si, že Outlook replikuje z Exchange tisíce, nebo miliony jednotlivých mailů a schůzek. Asi těžko to bude dělat tak, že by při každém spuštění projel seznam všech mailů, které jsou v Exchange a porovnal to s tím, co má u sebe, a zbytek si dostáhl. Že? Samozřejmě stahuje jen "novinky".

Na druhou stranu musí být schopen zpět do Exchange uložit všechno, co se u něho vytvořilo v průběhu doby, co byl odpojen od sítě. Na to tam přece právě máte ten offline mode.

Příklad - jste offline, vytvoříte si v Outlooku nový kontakt, a nějaký jiný si upravíte. Za hodinu se připojíte a Outlook tyto dvě modifikace nahraje zpět do Exchange. Jakmile aktualizace na nějaké položce proběhne, už nikdy se nedělá znovu. Proč taky, že? Takže položky, které už byly synchronizovány, se znovu nesynchronizují.

Co je "nové" se pozná podle nějakého celosystémového čítače, obvykle. V případě Active Directory se to nazývá universal serial number (USN). Jak se to jmenuje v Outlooku nevím.

Co se stane, když vy jednu stranu replikace natvrdo vrátít v čase zpět? Řekněme, že vrátíte zpět Exchange databázi o jeden den. Vrátíte zpět snapshot/checkpoint, nebo Hyper-V replica. Exchange se vrátí zpět, aniž by to sám věděl. Nebude mít tedy nějaké kontatky a maily, které jsou v OST souborech na klientech. Jenže Exchange neví, že byl vrácen zpět. Neví to ani Outlooky.

Znamená to, že položky, které byly synchronizovány v té "obnovovací díře" se už nikdy nebudou synchronizovat z Outlooku zpět do Exchange. V Exchange mailboxu budou tedy chybět buď úplně, nebo tam budou ve své starší verzi. To je mejhem! Každý Outlook bude nějak poškozen.

Jaký by byl rozdíl, kdybyste provedli skutečnou obnovu Exchange databáze? Provedli byste to za plného vědomí Exchange. Exchange by sám věděl, že byl vrácen o nějaký čas zpět. Tohle by řekl všem klientům. A všechny Outlooky by provedly násilnou re-synchronizaci všech položek, které byly změněny v oné "obnovovací díře".

To je důvod, proč Exchange nepodporuje obnovu ze snapshot/checkpoint/image/replica. To je důvod, proč to nepodpruje skoro nikdo. Kromě Active Directory na Windows 2012, pokud virtualizační platforma nabízí GenerationID. Ale já tomu stejně nevěřím. Je jednoduché to poškodit.

Vemte si jiný příklad WSUS a aktualizací na stanicích. Jak probíhá detekce? Myslíte, že Windows Update client pokaždé projíždí celý seznam všech nabídek? Nebo si stanice pamatuje co už všechno chtěla/nechtěla a znovu to nedetekuje? Můžete tedy ze snapshot/replica vrátit WSUS server? To já nevím.

Co vím, je že nikdy nevíte, dokud vám výrobce konkrétní aplikace nepotvrdí, že to umí. Tak jako to potvrzuje v případě Active Directory. Jak se chová DNS? Jak se chová DHCP replika? Jak se chová certifikační autorita a certifikátoví klienti? Vy to víte? A garantujete?

V ostatních případech musíte bezpodmínečně provádět korektní podporovanou aplikační obnovu ze skutečné aplikační zálohy. Takže i pro WSUS atd.

Nikdy nevíte.

To je stejné, jako když máte nějaký hardware mirroring na diskovém poli. Na to, aby to fungovalo korektně, musíte mít synchronní mirroring. Tzn. na druhém poli máte data synchronně mirorovaná ještě předtím, než pole dá vědět OS, že se data zapsala. To je drahé jako peklo.

Na co je tedy snapshot/checkpoint

Samozřejmě na pokusy. Pro obnovu to můžete také použít, jako startovní bod. Nahodíte snapshot BEZ SÍŤOVÉHO PŘIPOJENÍ a až to naběhne, provedete uvnitř korektní aplikační obnovu. Teprve potom můžete připojit do zbytku prostředí.

Na co je Hyper-V replika

Hyper-V replica může sloužit zase jako startovací bod pro manuální aplikační obnovu, stejně jako checkpoint. Na co je ale výborná je plánovaný failover (planned failover). Tedy přenos virtuálního počítače plánovaně na totálně jiný Hyper-V hostitel. Tady nenastává problém s vracením se k minulému stavu, ale plynule přecházíte z jednoho hostitele na druhého.

A samozřejmě na pokusy. Na to tam je právě ten "application consitent recovery point".

Hyper-V replika a application consistent recovery point

Co to je? Když se dělá replika, je to trošku divné. Replikuje se totiž jen storage. Tedy VHD a VHDX. Za jízdy virtuálního stroje. Pokud obnovíte nějakou repliku (tzn. neděláte planned failover), tak obnovujete vlastně stroj, který jste vytrhli z napájení. Tedy po tvrdém restartu.

V takovém případě vám nemusí už databázový systém (speciálně Exchange) naběhnout. Prostě vytrhnout Exchange, AD, nebo DHCP a certifikační autoritu, nebo i jen registry z napájení může být smrtící. Hyper-V replica umí tedy vyžádat, před odkopírováním, volume shadow copy (VSS), kdy se aplikace dozví, že bude vyrvána ze zásuvky a korektně se na to připraví.

Je tedy Hyper-V replica backup? Ne!!!

Znamená to, že pokud obnovíte starší obyčejný recovery point, tak nemusí vám ta virtuálka naběhnout vůbec. Zatímco když obnovíte starší application consistent recovery point, virtuálka vám zaručeně sama o sobě naběhne v pořádku. Ale do sítě to stejně pustit nemůžete, protože jste obnovili ve skutečnosti snapshot/checkpoint. Tak bacha!

Co z toho plyne?

Virtualizace sama vám nikdy v životě nemůže nabízet službu spolehlivého zálohování a obnovy. Obnovu musíte vždy provádět podle návodu výrobce každé jednotlivé aplikace, kterou provozujete! Musíte obvykle zálohovat "uvnitř virtuálního počítače" pomocí nějakého agenta a obnovit to opět uvnitř jedoucího a vědoucího virtuálního počítače a jeho aplikace.

srpen 12
Upgrade VMWare je svině, jak já říkám pořád

Zákazník má hostované serverové prostředí v cloudu. Pánové z obláčku to provozují na VMWare. Údajně dělali nějaký upgrade VMWare i jeho "hardware" nebo co. Těmhle VMWare kravinám já nerozumím a ani rozumět nechci. Protože už jsem po několikáté zažil, že ty jejich síťovky jsou šmejdy.

Oni totiž při upgrade hardware musí změnit to zařízení síťovky. Tedy změní jeho identifikaci ve Windows (asi PNP ID) a tím pádem se ta původní síťovka ztratí a objeví se nová. Nový hardware. Takže se na síťovce samozřejmě vytratí i IP konfigurace. VMWare Tools k tomu přistupuje bojovně a prostě se snaží to nějak ohekovat a konfiguraci přenést.

Akorát, že to dělá blbě.

Tentokrát se mu nepodařilo přenést nastavení DNS serverů na novou síťovku. To by si ještě dokázal opravit každý skoro na první pohled. Dobrá.

Ale to druhé, co to udělalo je děs. Z registrů to odstranilo hodnotu NV Domain z klíče HKLM\System\CurrentControlSet\Services\TcpIp\Parameters. To jsou kreténi!

Tahle hodnota obsahuje primary DNS suffix serveru. Tohle byl dokonce řadič domény (domain controller). Proč na to vůbec sahají? Bože. Speciálně na DC. Co myslíte, že se asi pak stalo, po restartu. Už ta doména nejela.

Naštěstí jsem neuvěřitelně dokonalej AD mástr, takže jsem na to přišel vcelku rychle. Ale tohle dělat? Prostě jako u kreténů. Co jiného můžete čekat od víjemvývaru? Navrhuju přejít bleskově na Hyper-V. Microsoft aspoň ví, co má a co nemá dělat ve svých Windows.

červenec 06
Vytvoření bootovacího Windows instalačního flash disku

Omlouvám se všem, že tady píšu zrovna tuhle tisíc let starou záležitost, ale dneska jsem to zrovna potřeboval a - světe div se - nenašel jsem to u sebe na webu, i když jsem si byl 100% jistej, že jsem to sem dával.

Takže pardon. Prostě to berte tak, že to tu musím mít taky:

Jak se naformátuje USB flash disk tak, abych na něho mohl nakopírovat instalační médium operačního systému Windows Vista, Windows 7, Windows 8, Windows 8.1 nebo třeba i Windows 2012 a Windows 2008 serverů?

Je to jednoduché, jenom musíte překonat problém, že normální flash klíčenka se netváří jako regulérní harddisk - tzn. nemá master boot sektor. To co dostanete, když si koupíte USB flešku, je v podstatě disketový formát - má to jenom boot sector. Normální harddisk, byť jen s jedním oddílem musí mít ale i master boot sector.

Takže postup je ten, že musíte váš flash disk vyčistit a pomocí nástroje diskpart na něm vytvořit správnou harddiskovou strukturu:

diskpart
list disk
select disk <cisloVasehoFlashDisku>
clean
create partition primary
select partition 1
active
format fs=ntfs quick label=osinstall
assign

Na teď už do toho jenom nakopírujete obsah instalačního ISO, nebo DVD média.

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
4.9.2014 19:14
Euforie z Office365 podporu! Nemuzu si pomoct, ale musim vyjadrit obrovske nadseni z borcu z podpory na Office365. Ne ze by me pomohli :-) ale snazi se a jsou velmi ochotni. Diky do Svedska!
4.9.2014 8:29

vsechny Windows Live ucty zamknuty? Ze by mel MS nervy z celebrit?

1.9.2014 18:09

Ubytování v Ostravě za 1400,- na 4 noci s kabelovým internetem 6 MB, vlastní pokoj velmi nově opravený a zařízený, s kuchyňkou a sociálkou. Panebože!!! To je skoro lepší se sem úplně přestěhovat!

 

22.8.2014 4:40
Dekuji vsem za prizpevky a komentare!
20.8.2014 12:37
Zda se, ze instalace DC 2012+ dela kontrolu ostatnich DC pomoci WMI
18.8.2014 20:13
Dneska alza reklama - dum a auto si zamykate, tak proc si nechranite pocitac antivirem?

Na to meje odpoved - protoze tam mam antivirus od MS, ktery funguje stejne jako zamek doma a od auta - neznici vam motor, nezpomalǔi vam auto trikrat a chaoticky neblika levym a pravym blinkrem a nebrzdi ve stopadesatce znicehoz nic
12.8.2014 10:09
dneska jedna zajímavost - tu u zákazníka zmizel na DC po výpadku proudu primární DNS suffix. Prostě to bylo najednou bez suffixu. Co se stalo ve skutečnosti je, že zmizel klíč z registrů - HKLM\System\CurrentControlSet\Services\TcpIp\Parameters, hodnota "NV Domain". Tak jsem to nastavil znovu ručně a už to funguje. Divnost nad divnost.

11.8.2014 12:01
je škoda, že nejde zvýšit karmu víckrát, než jenom jednou:
http://vetvicka.blog.idnes.cz/c/421436/Zastavte-Putina-dokud-je-cas.html
15.7.2014 20:07
Tak to jsem se musel fakt smat - http://www.dfens-cz.com/view.php?cisloclanku=2014071501 - "britove a francouzi take maji letadlovou lod" :-D
9.7.2014 16:19
Jak poznáte, že máte nainstalován Windows 2012 R2 "Update"? Spustíte MSINFO32 a v položce Hardware Abstraction Layer musí být hodnota alespoň 6.3.9600.17031.

8.7.2014 11:41
Aaa, tak jenom jsem se trošku unáhlil - na to, aby Network Monitor zobrazoval i pakety, které přicházejí do Destination virtuálního počítače ze Source počítače - je potřeba pro tu danou sledující síťovku zapnout P-Mode. To uděláte v Network Monitoru například v Capture Settings, nebo rovnou na Start Page je dole čudlík - pozor, pro každou síťovku zvlášť. Takže port mirroring v Hyper-V už není žádný problém ani s Network Monitor.
8.7.2014 11:35
tak zdá se, že Network Monitor od Microsoftu neumí zobrazovat pakety, které přijdou přes port mirroring v Hyper-V do Destination virtuálního počítače. Když jsem si nainstaloval Wireshark a WinPCap, tak úplně v pohodě. Jdu to prozkoumat ještě o trošku více, třeba se to dá někde v Network Monitoru zapnout.
6.7.2014 15:42
Tývolé, co to jéé: Internet Explorer has modified this page to help prevent cross-site scripting
5.7.2014 16:23
Hodni slovensti policiste mi naparili pouze 20Eur pokuty. Kluk a holka zrejme nemeli radar, pac jinak bych uz nejspis nejezdil :-)
5.7.2014 16:23
Cukrarna Dino ve Zline opet nezklamala svou uuuuuzasnou zmrzlinou!
24.6.2014 8:52
pokračování úspěšné série o dírách v SuperMicro - aneb dorazilo mailem:

vami uvedeny problem byl resen a vyresen jiz v lonskem roce novou verzi IPMI firmwaru. Viz. odkaz nize.
http://www.supermicro.com/support/faqs/faq.cfm?faq=16536

Upgradujte si prosim IPMI na posledni moznou verzi nejlepe na vsech vasich serverech.
23.6.2014 19:16
dorazilo poštou. přikládám v nepozměněné formě:

V Supermicro pracujou odborníci :)

Bezpečnostní tým CARI.net, zjistil, že IPMI/BMC - Supermicro základních desek obsahuje binární soubor, který ukládá přihlašovací hesla ve formátu prostého textu a je k dispozici ke stažení soubor pouhým připojením ke konkrétnímu portu 49152. Pokud je management dostupný z internetu, je možno tento soubor snadno získat "GET /PSBlock". Team provedl skenování a získal tak hesla k 32 tisícům serverů. Je dost zarážející, že je management u tolika serverů dostupný z internetu. A ještě víc zarážející je, kolik hesel bylo defaultních.
http://www.root.cz/clanky/postrehy-z-bezpecnosti-karty-supermikro-umoznuji-stahnout-hesla/

A já potvrzuju, že to fakt funguje, na heslo se prostě člověk podívá na adrese http://ip_adresa_IPMI:49152/PSBlock

23.6.2014 15:42
No musim teda rict, ze oproti vsem moskevskejm nadrazim, na kterejch sem byl a metro stanicim, tady v Brne na hlavnaku je me na zvraceni. A napriklad takova Beloruskaja je uplne atmosfericka.
23.6.2014 14:50
Čéééeeeeeééééeeeeéeeéééeskóóóóóóóó!
23.6.2014 11:46
Prave sme dosedli ve Vidni. Po ceste se krasne menila krajina - v Rusku sirokodaleko nic, v obcasne vesnicce hnedy silnice (no asfalt baby), stokilometrovy pruseky lesu neznamejch ucelu, obcas pouzity na draty. V Belorusku zmena pustiny na pustinu bazinatou. V nekolika mistech regulovany baziny. Vesnicky stejne jako v rusku z vrchu vypadaji jako smetaky. Na hranicni care s Polskem zmena jako prase - vsude policka, pekny organizovany nahusteny vesnicky, silnice sede (tzn asfalt), obcas hlinene pruseky v mistech kde se stavi dalnice, puda vyuzita a organizovana do posledniho metru. Slovensko nadherny vesnicky v kopcich, malinke, ale utulne, vsechny strechy barvy normalnich tasek a ne dosek porostlych mechem (tak to bylo uz v Polsku). Prelet do Raichu, vsude vetrniky, jak u blbejch :-)
23.6.2014 6:53
... ani prestavam si byt jisty, ze ten burgerking byl alespon neskodne prijatelna varianta. Ale tak snad to vyjde rychle a bezbokestne :-)
23.6.2014 6:53
Vnukovo letiste je parada. Ve dvou kavarnach maji prd ve forme dvou zakusku a sendvice, ze kteryho je me na pohled na bliti. A pak burgerking, coz na snidani neni nic, ale lepsi nez dratem do voka. Internet na pul hodiny a nejde me zmenit MAC adresa, sakra.
22.6.2014 22:23
Total mayham. Na mezinarodnim letisti nekdo neumi anglicky? Tak tady na Vnukovu nemluvi ani slovo anglicky ani borec na checkinu, ani jedna pani ve vobchode s vodou, ani dva borci na security ceku. Vcelku jsem se nedivil, ze to tak vypada ve 4* hotelu v Uglici, ale tady? Paneboze!
22.6.2014 19:10
Zase zpet v Moskve. V baru Help na veceri a pomalu odjezd na letiste.
22.6.2014 16:05
Tak uz jsme 2 hodiny na ceste busem dom. Vsude jenom lesy, louky, obcas dum, jinak prd. Nechapu. Pritom takova normalni krajina. Neobdelana pole, pripadne prolezla plevelem. Tak jeste udajne 2 hodiny do Moskvy, potom hodinu na letiste, potom tam budu sedet do 10 do zitra a pak konecne domu :-)