Het is mij opgevallen dat format-list soms een vreemd gedrag vertoont. Het toont niet altijd alle properties. Een goed voorbeeld is het volgende commando

Get-ExchangeCertificate | fl

Vergelijk de output maar eens met:

Get-ExchangeCertificate | fl *

Dit zou volgens de syntax niets uit mogen maken. Ik heb een vraag uitstaan bij MS, maar bij voorkeur kan je dus beter de asterix gebruiken.

:)

EDIT:

Mow van http://thepowershellguy.com was zo vriendelijk uit te leggen hoe de spreekwoordelijke vork in de steel steekt met format-list.. Zo zie je maar.. Je leert elke dag weer wat bij.

Dank je MOW!!

Zijn reactie is te vinden onder dit artikel, maar voor de volledigheid zal ik het opnemen in het artikel:

Wanneer je geen * gebruikt word de default format data gebruikt.
Dit zijn de properties die bij default worden getoond.
de defaults zijn / worden opgeslagen in format files :

notepad $PSHOME\DotNetTypes.format.ps1xml

wanneer het type in deze file(s) gevonden wordt wordt deze format data gebruikt voor de default output :

een goed voorbeeld is :

dir | ft
dir | ft *

hier is de defenitie the vinden in :

notepad $pshome\FileSystem.format.ps1xml

dir $PSHOME *.ps1xml

je kunt met de update-formatdata Cmdlet ook je eigen “view’s” voor objecten toevoegen, de default formatfile is “gesigned” en kan beter niet aangepast worden.

doe er iets leuks mee ,

Groeten /\/\o\/\/

Heb je in Exchange 2007 wel eens OWA redirection geprobeert in combinatie met forms based authenticatie. Dat is dus niet echt geweldig. Het vereist je om twee maal in te loggen en daartussen moet je nog een keer op een link klikken. Ook moet je je 403.4 error page aanpassen om initieel je gebruikers door te verwijzen naar de OWA virtual directory achter port 443. Allemaal erg omslachtig.

Voor deze mensen heb ik een oplossing...

In de SDK voor Exchange 2007 SP1 vond ik een mooie Autodiscover proxy class, waarmee je heel gemakkelijk de autodiscover service kon aanspreken. Alle logica voor het polsen van het Service Connection Point en anders DNS staat daarin. Dit bracht mij op het idee om even quick en dirty in ASP.net een redirection page te maken waarmee op basis van de Windows Credentials een user doorgestuurt wordt naar de juiste CAS.

Het is heel simpel te implementeren:

1. Creeer een directory voor een nieuwe website (bv: C:\InetPub\OwaRedirect)
2. Pak de Owa Redirection zipfile uit in deze directory.
3. Creeer in IE een nieuwe website, waar alleen Windows Integrated Authentication wordt toegestaan en zet de permissies op 'Read' en 'Run scripts'.
4. Bind de site aan een secondary IP of werk met host headers (zorg dat als je met ip binding werkt, je ook de default web site bind aan een bepaald IP)
5. Creeer een A record voor deze site (je kunt deze site op meerdere servers hosten en met DNS round Robin werken; werkt uiteraard ook in NLB).

Wanneer je nu naar deze site browsed zal deze je meteen doorlinken naar de juiste CAS server (mochten er meerdere CAS servers zijn in de site, zal hij er random 1 kiezen).

Mocht je problemen hebben, wijzig in default.aspx.cs de variabele bolDebug naar True om te zien wat het response is van de Autodiscover service.
 public bool bolDebug = true;

Zoals ik al aangaf is dit quick en dirty, dus mocht je verbeteringen hebben, laat het me weten.

Altijd al willen weten hoe bij Microsoft de Exchange omgeving erbij staat. Dat kan nu... Een projectsamenvatting is HIER te vinden...

Met de release van Windows Server 2008 in het vooruitzicht, wordt het tijd wat meer te weten te komen over dit nieuwe OS. 1 van de belangrijkste wijzigingen in het OS is de mogelijkheid een minimale versie te installeren. En met minimaal, bedoel ik ook echt minimaal. Nagenoeg alles wat eruit gehaald kon worden is eruit gehaald. Zo heb je geen MMC, geen .NET framework, geen explorer met fancy GUI en de enige bureau accessoire is notepad, welke initieel ook niet beschikbaar was, maar onder druk van de betatesters is toegevoegd.
Na installatie van de Server core is het de bedoeling dat er een rol of 'feature' geinstalleerd wordt. Dit artikel zal de installatie van een Server Core Domain Controller behandelen.

Server Core ondersteunt de installatie van de volgende rollen:

• DHCP
• File Server
• DNS
• Active Directory

Naast deze rollen kunnen de volgende 'features' geinstalleerd worden.

• Microsoft Failover Cluster
• Network Load Balancing
• Subsystem for UNIX-based applications
• Backup
• Multipath IO
• Removable Storage Management
• Bitlocker Drive Encryption
• Simple Network Management Protocol (SNMP)
• WINS

Installatie van deze extra rollen en features kunnen worden uitgevoerd door gebruik te maken van OCSETUP, een van de commandline utilities die gebruikt dienen te worden om de server te configureren. Dit geldt voor alle rollen en features, behalve voor de Domain Controller rol. Deze dient, als vanouds, geinstalleerd te worden door DCPROMO in unattend mode te draaien. Voordat ik dat behandel zal ik eerst ingaan op de installatie van Server Core zelf.

Voor de installatie maak ik gebruik van Release Candidate 1 van Windows Server 2o08 in Virtual PC 2007. Deze is te downloaden via MSDN. Onderstaand "stripverhaal" toont de installatie.

De installatie is nu voltooit. Nu rest de configuratie en de installatie van de DC rol.

Om de server core te configureren heeft Microsoft een verzameling tools meegelevert, welke niet allemaal even charmant zijn en zeker ook niet erg consistent in syntax. Zo dien je bijvoorbeeld Remote Desktop en Automatic Updates te configureren via een vbscript. Ik persoonlijk vind dat een beetje goedkoop. Het had best een gewone binary kunnen zijn. Ook het feit dat de ene tool de parameters scheidt met een slash en de andere met een minteken, vind ik typerend voor een systeem wat afgeraffelt is en niet iets wat in een nieuw OS zou moeten zitten. Maar goed, we moeten het er nu mee doen.
Het kost te veel tijd om op elke setting in te gaan, maar de volgende settings zorgen voor een redelijk bruikbaar systeem. We beginnen met de configuratie van het netwerk. Hiervoor gebruiken we NETSH. Het instellen van een ip address, default gateway en dns server voor een interface met naam 2 gaat als volgt:

netsh interface ipv4 add address name=2 address=192.168.1.100/24 gateway=192.168.1.1
netsh interface ipv4 add dnsserver name=2 address=80.80.80.2

Vervang dus de name door de interface naam, bijv: "Local Area Connection". De rest spreekt voor zich :) 

De computernaam is te wijzigen met netdom renamecomputer %computername% /newName:DC1

Nu de netwerkinstellingen goed staan is het tijd services als Remote Shell en Remote Desktop te activeren. Ook het OS moet nog geactiveerd worden. Windows Remote Shell activeer je door WinRM QuickConfig. Hierna is de server op afstand te beheren door WinRS -r:. Remote Desktop en Automatic Updates zijn te configureren met het script SCregEdit.wsf. Gebruik het met de /? optie om alle mogelijkheden te zien. Voor het activeren van Remote Desktop gebruik je cscript %systemroot%\System32\SCregEdit.wsf /AR 0 en voor Updates gebruik je cscript %systemroot%\System32\SCregEdit.wsf /AU 4.

Last, but not least, moet het product nog geactiveerd worden. Dit doe je door slmgr.vbs uit te voeren. Het weergeven van de huidige licentiestatus is cscript slmgr.vbs -dli. Het activeren gaat met cscript slmgr.vbs -ato

Nu kan het zijn dat de build die je gebruikt vereist dat je een Key Management Services (KMS) Server beschikbaar hebt om je OS te activeren. Je kan dan proberen dit te omzeilen door de preinstalled key te vervangen met je eigen key, waarna je opnieuw probeert te activeren. Het wijzigen van de key gaat als volgt:

cscript.exe slmgr.vbs -ipk ABCDE-FGHIJ-KLMNO-PQRST-UVWXY

Nu de server de benodigde basisinstellingen heeft, kan de DC rol erop gezet worden. In Windows Server 2008 is er nu onderscheid tussen schrijfbare en read-only domain controllers. Beide typen kunnen geinstalleerd worden op een Server Core installatie. Zoals eerder gemeld, moet Windows Server 2008 net als voorheen gepromoveert worden tot Domain Controller door gebruik te maken van DCpromo in unattended mode te draaien. Dit kan via commandlineparameters of via een text file. De unattend text file heeft een bepaalde syntax zoals HIER en HIER staat uitgelegd.

Om ADS te installeren inclusief DNS voor een nieuw Forest in Windows 2008 operational level, kan je volstaan met het volgende commando:

dcpromo /unattend /InstallDns:yes /dnsOnNetwork:yes
/replicaOrNewDomain:domain /newDomain:forest
/newDomainDnsName:test.local /DomainNetbiosName:TEST
/safeModeAdminPassword:FH#3573.cK /forestLevel:3
/domainLevel:3 /rebootOnCompletion:yes

Na afloop heb je een functionele Server Core writable Domain Controller...

Enjoy :)

Naast het feit dat ik een mailsysteem geen plek vind om informatie met elkaar te delen, ben ik deze week achter nog een reden gekomen waarom public folders uit Exchange 2007 moeten verdwijnen. Dit heeft alles te maken met een probleem waar ik een maand mee bezig ben geweest...

Vorige maand is de klant waar ik momenteel voor werk een Exchange 2007 pilot gestart in een redelijk grote bestaande Exchange 2003 organisatie. Deze omgeving telt 100+ servers verspreid over 4 continenten. Daarbinnen hebben ze 52 Public Folder stores.

De initiele pilot groep telde +- 30 gebruikers, welke in UAT uitgebreid zou gaan worden naar +- 250 gebruikers. Vanaf het begin af aan kreeg ik klachten dat geheel willekeurig een Outlook client ineens bleef hangen voor 1 a 2 minuten, waarbij "retrieving data" popups verschenen, welke verwezen naar de 2007 public folder server die opgetuigd was voor de pilot users. Na verschillende perfmon sessies te hebben gedraaid op deze server, kon ik geen performance issues vinden. De hardware functioneerde prima, en ook de lokale GC's lieten geen problemen zien. Wel zagen we om het half uur hoge "RPC average latency" pieken. Na ook met network monitor aan de slag te zijn gegaan konden we zien dat de server elk half uur een waslijst aan Exchange servers verspreid over het hele forest aan het benaderen waren. We konden alleen zien dat het NetLogon verkeer was, aangezien de content encrypted is.

Microsoft werd erbij gehaald, maar na een week ploeteren hadden we nog geen inzicht in wat het probleem nou precies was. We hadden in de tussentijd al van alles gedaan. IsInteg gedraaid, andere public folder stores geprobeert. Aangezien de problemen zo willekeurig optraden konden we niet goed zien wat er nu precies gaande was. Het leek erop dat het probleem vaak optrad bij het opstarten van Outlook. Echter waren er ook berichten dat het ook gebeurde als iemand andere zaken aan het doen was of zelfs helemaal niets aan het doen was. In een poging het probleem in de kraag te vatten had ik Netmon op mijn werkstation weten te krijgen (is gesloten omgeving dus was een hele klus om toestemming te krijgen). Door via script Outlook om de 7 seconden te openen en te sluiten, hoopte ik te kunnen tracen wat Outlook nou precies vraagt, waar Exchange nu zo'n moeite mee heeft. na 3 uur had ik beet. Na de capture opgestuurt te hebben naar Microsoft (zij kunnen namelijk delen van RPC pakketjes decrypten), bleek dat het om een request te gaan waarbij Outlook vroeg op content van de "Outlook Security Forms". Om er zeker van te zijn moesten we proberen nog een packet te capturen, maar tegelijkertijd ook een perfmon en netmon sessie op de server te starten.

Dit bleek lastig aangezien we al moeite hadden het te triggeren met script. Op mijn werkstation was het al meer dan een week niet "zomaar" voorgekomen. Na intern overleg had ik toestemming op nog een aantal werkstations netmon te installeren. Echter bleek dit niet nodig te zijn, want na ik wat beter naar de netmon capture van de server te kijken en naar de perfmon sessie, kon ik een patroon vinden waarbij er telkens om het half uur een RPC request gedaan werd, waarna Exchange al die PF servers afging. Nadat dat klaar was, kwam er een RPC response, en precies op dat moment schoot de RPC average latency omhoog. Microsoft vroeg mij verschillende malen memorydumps te maken van store.exe. Tijdens de rpc peak, vlak voor de rpc peak etc etc. In totaal hebben we 15 GB aan dumps op moeten sturen. In de tussentijd was er een CPR engineer onsite geweest omdat MS zelf ook niet wist wat er nu precies gaande was. Veel meer dan meekijken kon hij niet. Kreeg meer de indruk dat hij kwam kijken of we de boel niet voor de gek aan het houden waren.
Enfin, Na een paar dagen was Microsoft klaar met het analyseren van de memory dumps en wat bleek. Het probleem werd veroorzaakt doordat Outlook de Public Folder hierarchy wilde laten reloaden. Dit kwam doordat er public folder stores in de hierarchy zaten die niet meer bestonden. Dit kan komen doordat public folder stores voor Exchange 2003 sp2 gewoon verwijdert konden worden, zonder de replicas te verplaatsen naar andere servers. Nu had ik in die omgeving al een keer een schoningsactie gehouden waarbij System folders van oude stores verwijdert waren en de replicalijst aardig schoon was (replstate test van ISINTEG schoont deze op). Echter het blijkt dat de replicalijst ook nog op andere plaatsen in de PF store opgeslagen wordt. Deze "orphaned" entries op die plek kunnen dus niet verwijdert worden en zorgen ervoor dat ze blijven voorkomen in de hierarchie. Outlook ziet de guids van deze nietbestaande PF stores en zal elke keer wanneer het de hierachie opvraagt vragen om een reload. Nu doet Exchange dit standaard 1 keer per uur, maar op aanvraag doet Exchange dat dus sneller, als er maar minimaal een half uur tussen zit.... Laat dat nu net de interval zijn dat we die high latency pieken zien.

Wat blijkt nu? In Exchange 2003 hadden we dat probleem dus ook, maar hadden we geen Outlook clients die hingen. Dat komt omdat de reload van Exchange 2003 veel sneller ging. In Exchange 2003 gebruiken we routinggroup connectoren met costs. Door een paar snelle AD queries kan Exchange dus heel snel de hierarchie opbouwen.
In Exchange 2007 gebruiken we echter AD sites met costs. Echter op een serverobject in AD staat niet in welke AD-site deze zit. Exchange moet dat dus zien te bepalen. En waar hebben de programmeurs voor gekozen??? ...Precies... Een sessie opzetten met de server om zo de site te achterhalen. Vandaar dat we de Netlogons zagen. En servers in Azie en Australie reageren nu eenmaal niet zo snel als ze achter high latency lijntjes zitten. Dus om het half uur wachtte een client totdat Exchange sessies had opgezet naar 52 PF server in de organisatie.

Hoe nu verder? Nou... Niet met Exchange 2007 public folders dus voorlopig. Als het aantal is teruggebracht van 53 naar 8, dan kunnen we erover denken, maar nu niet.
Er is wel de mogelijkheid om het interval van reloaden aan te passen. Dit doe je door een DWORD aan te maken in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsExchangeIS\\Public-(guid)

Dit DWORD moet heten "Replication Reload TLH Min" en de waarde is het aantal seconden die minimaal moeten zijn verstreken sinds de laatste reload. De maximale waarde is 43200 decimaal (12 uur). Zo kan je ervoor zorgen dat het probleem slechts 1 keer per 12 uur optreed. De enige echte structurele oplossing is om de hele PF tree opnieuw op te bouwen. Dat is echt heel erg lastig in grote omgevingen.

Omdat de programmeurs niet echt handig zijn omgesprongen met het reloaden van de hierarchie in Exchange 2007 is dit probleem nog in onderzoek bij de productgroep. Hopelijk wordt er een aanpassing gemaakt. Misschien wordt dit zelfs als bug aangeduid. Hoe het ook wil, op dit moment zijn public folders in grote omgevingen dus RUK...

Van mij mogen ze verdwijnen.