Een agenda van een andere gebruiker openen in Outlook is niet zo’n hele grote uitdaging, wanneer je voldoende rechten hebt kun je bij de agenda van de gebruiker. Maar wat nu als je dit via OWA wil doen? Voor de verschillende Exchange versies gelden verschillende manieren, laten we beginnen met Exchange 2003:
http://ex01.company.om/exchange/johan/calender
Waar in dit geval johan de variabele is en vervangen dient te worden door de gebruikersnaam van de persoon wiens agenda je probeert te openen.
Voor Exchange 2007 en Exchange 2010 geldt echter iets anders, dit heeft te maken omdat zowel Exchange 2007 als 2010 gebruik maken van web-parts om de verschillende OWA onderdelen op te bouwen. Natuurlijk heeft OWA de mogelijkheid om een andere gebruiker zijn/haar mailbox en vervolgens de agenda te openen maar hier heb je full mailbox access voor nodig, iets wat niet altijd wenselijk is. Om direct de agenda te openen van een gebruiker dien je onderstaande syntax te gebruiken:
https://owa.company.com/owa/johan@domain.com/?cmd=contents&module=calendar
Zoals je ziet is alleen het laatste deel veranderd johan@domain.com/?cmd=contents&module=calendar. Naast deze manier zijn er nog diverse andere mogelijkheden in Exchange 2007 en 2010 om een agenda weer te geven, onderstaand een opsomming:
https://owa.domain.com/owa/johan@domain.com/?cmd=contents&f=calendar&view=dialy
Het bovenstaande command opent de agenda, dit wordt gedaan middels de f parameter welke het mogelijk maakt een map te openen welke zich in de mailbox van de gebruiker bevindt. Vervolgens geven we met de view parameter aan hoe de agenda moet worden weergeven, in dit geval dialy. Wanneer deze laatste parameter niet wordt opgegeven zal dit tevens de standaard optie zijn.
https://owa.domain.com/owa/johan@domain.com/?cmd=contents&f=calendar&view=weekly
Dit commando doet exact hetzelfde alleen opent deze de agenda met de weekly view.
https://owa.domain.com/owa/johan@domain.com/?cmd=contents&f=calendar&view=monthly
En als laatste de monthly view, tenminste dat zou je denken we hebben nog een mogelijkheid:
https://owa.domain.com/owa/johan@domain.com/?cmd=content&f=calendar&view=daily&d=10&m=26&y=2010
Bovenstaande commando opent de agenda en zal hierbij gelijk naar 26 oktober 2010 gaan.
Gepost in Exchange ~ Geen Reactie
Microsoft heeft voor zowel Exchange 2000 SP3, Exchange 2003 SP2, Exchange 2007 SP1 en SP2 als Exchange 2010 een security update vrij gegeven. Voor Exchange 2007 en 2010 is deze patch uitgebracht als onderdeel van een rollup. Hiermee bereiken we rollup 10 voor Exchange 2007 SP1, rollup 4 voor Exchange 2007 SP2 en rollup 3 voor Exchange 2010.
Alle updates bevatten een security fix voor een vulnerability die is ontdekt in de Windows SMTP service waardoor het mogelijk is een DOS attack uit te voeren.
Onderstaand de links waar je de patches kunt vinden en een link naar het security bulletin welke de vulnerability beschrijft.
Exchange 2000 SP3: open
Exchange 2003 SP2: open
Exchange 2007 SP1: open
Exchange 2007 SP2: open
Exchange 2010: open
Microsoft Security Bulletin MS10-024: open
Gepost in Exchange ~ Geen Reactie
Soms zijn er nog weleens discussies of het nou wel of niet wordt ondersteund om bestanden op een fileserver te plaatsen en dus te benaderen via een LAN/WAN verbinding. Het antwoord daarop is nee, officieel wordt het niet ondersteund vanuit Microsoft. Maar wanneer je het in de praktijk gaat proberen zal het best gaan werken dus waarom wordt het nou niet ondersteund ?
De betreffende bestanden worden middels een zogenaamde file-access-driven methode gebruikt om data op te slaan. Hiervoor wordt gebruikt gemaakt van speciale file access commando’s die het OS aanbiedt om bestanden te kunnen lezen en schrijven.
Voor het schrijven naar lokale disken is dit een uitstekende methode maar voor het schrijven naar een fileserver via een LAN/WAN wordt hiervan geen gebruik gemaakt. In plaats van de file-access driven methode wordt hier gebruik gemaakt van een network-access-driven methodes. Het OS bevat ook voor deze methode commando’s om data te verzenden/ontvangen van/naar andere systemen die zijn aangesloten op het netwerk.
Maar wat doet Outlook in het geval een PST op het netwerk staat? Outlook zal proberen via file commando’s het bestand te lezen of er naar te schrijven. Omdat het bestand echter op het netwerk staat zal het OS deze commando’s vervolgens over het netwerk versturen naar de server waarop het bestand zich bevindt.
Dit veroorzaakt allemaal natuurlijk de nodige vertraging omdat er dus extra stappen uitgevoerd dienen te worden voordat de data uiteindelijk benaderd kan worden.
Naast de performance problemen die je kunt ondervinden kunnen de volgende problemen optreden:
- bestanden kunnen corrupt raken door bijvoorbeeld netwerk problemen
- schrijf- kunnen tot 4 keer langer duren dan lees acties
Mocht je nog wat meer informatie willen hebben dan kun je op onderstaande sites terecht:
Ask the Performance team: Network stored PST files …. don’t do it! open
Configuring Outlook for Roaming Users open
Gepost in Exchange ~ Geen Reactie
Het is al geruime tijd mogelijk om een OCS omgeving aan een Exchange omgeving te koppelen. In eerste instantie was dit alleen mogelijk met de Exchange UM server waardoor je de voicemail, subscriber access en auto attendant van Exchange kon gebruiken in OCS.
Sinds kort gaat de integratie nog een stapje verder, het is nu mogelijk om een beperkte OCS client te integreren in OWA. Zo wordt het mogelijk om berichten via IM uit te wisselen via OWA en wordt de presence informatie in OWA weergeven.
In deze tutorial leg ik uit hoe je deze nieuwe feature kunt installeren.
open
Gepost in Tutorials ~ Geen Reactie
Microsoft heeft enige tijd geleden de OCS 2007 R2 Web Service provider vrij gegeven, hiermee wordt het mogelijk om een OCS met beperkte functionaleiten te integreren in OWA. In deze tutorial leg ik uit hoe je de OCS client kunt implementeren in de OWA van Exchange 2010. De software kan gedownload worden via onderstaande link:
Voordat je begint met het installeren dien je ervoor te zorgen dat de CAS server waarop je dit installeert een geldig certificaat heeft en dus vertrouwd wordt door de OCS server. Wanneer je de bestanden hebt gedownload kun je aan de slag met het installeren. Het bestand CWAOWASSPMain bevat 4 losse bestanden en de patch file bestaat uit 1 MSP bestand, deze dienen in onderstaande volgorde geïnstalleerd te worden:
- vcredist_x64
- UcmaRedist.msi
- UcmaRedist.msp
- CWAOWASSP
Wanneer de bestanden zijn geïnstalleerd is het tijd voor de configuratie zelf. Hiervoor dienen we eerst een aantal eigenschappen van het certificaat te achterhalen wat gebruikt wordt voor de IIS service, dit kun je doen middels het commando get-exchangecertificate |fl. Vervolgens zoek je het certificaat op wat is gekoppeld aan de IIS service, de services waaraan een certificaat is gekoppeld zijn te vinden achter de services kolom. Hier dienen de waarden van de volgende twee velden gekopieerd te worden:
Nu we de waarden hebben gekopieerd is het tijd om het configuratiebestand van OWA aan te passen, dit is te vinden in c:\Program Files\Microsoft\Exchange\v14\ClientAccess\Owa. Hier zul je onder andere het bestand web.config tegenkomen, dit bevat de configuratie van Outlook Web Access. Maak voordat je begint een backup van het bestand en open het hierna met bijvoorbeeld Notepad. Zoek op IMPoolName om naar de sectie te gaan welke aangepast moet worden en pas hier het volgende aan:
- IMPoolName: vul achter value de naam van de OCS Pool in
- IMCertificateIssues: vul de zojuist gekopieerde waarde van issuer in, bijvoorbeeld: CN=company-DC01-CA, DC=Company, DC=Local
- IMCertificateSerialNumber: vul de zojuist gekopieerde waarde van het serialnumber in, bijvoorbeeld: 61580B7D00000000000E
Sla na het wijzigen het bestand op. Nu we de wijzigingen hebben toegevoegd aan het configuratiebestand vasn OWA is het tijd om de OCS client toe te voegen aan OWA, dit kunnen we doen middels het commando Set-OwaVirtualDirectory –InstantMessagingType. Op internet zijn er discussies over de waarde die moet worden opgegeven als waarde voor het InstantMessagingType. In de Technet documentatie staat dat je OCS als waarde op moet geven, echter ben ik op diverse fora tegengekomen dat dit mogelijk niet werkt. In mijn geval werkte dit zonder problemen, mocht je toch problemen hebben probeer dan eens i.p.v. OCS de waarde 1. Echter vermoed ik niet dat dit echt een oplossing is wanneer de integratie niet werkt. Ik heb namelijk zelf de parameter met de 1 geprobeerd in een werkende omgeving en kreeg toen netjes de melding dat er niks was gewijzigd. Om de OCS client te integreren met de OWA dien je onderstaand commando uit te voeren:
set-owavirtualdirectory -InstantMessagingType OCS
of
get-owavirtualdirectory -server servernaam |set-owavirtualdirectory -InstantMessagingType OCS
De Exchange kant is nu geconfigureerd, nu de OCS kant nog. Hiervoor dien je de OCS administration tool te openen en vervolgens de eigenschappen van de Front-end services op te vragen. Hier zul je de tab authorized hosts vinden. Hier dien je het volgende item toe te voegen:
Wanneer de fqdn is toegevoegd dien je de Front End service te herstarten om de wijziging te activeren. Als de service weer is opgestart en je zult inloggen via OWA dan zul je zien dat hier de OCS client aan toegevoegd is.
Zoals je bovenstaande kunt zien heb je de mogelijkheid om je huidige status te wijzigen en de status van andere gebruikers te zien. Naast deze uitbreiding is er een contactlist toegevoegd in de linkerhelft van OWA, deze lijst komt overeen met de contactlist in de MOC client.
Gepost in ~ Geen Reactie
Laatste tijd komt het wel regelmatig voor dat je spam ontvangt welke lijkt te worden verzonden vanaf een account in je eigen domein. Wanneer je echter op verder onderzoek uitgaat blijkt dit niet zo te zijn. Maar waarom trapt Exchange hier dan toch elke keer weer in. Het antwoord vond ik op Exchangepedia blog. Elke mail vanaf internet wordt geaccepteerd namens de Anonymous User, haal je deze gebruiker weg van de receive connector dan zal er geen mail meer van internet binnen komen. Deze gebruiker heeft natuurlijk een aantal rechten nodig om dit wel te mogen, een van de rechten is Ms-Exch-Accept-Authoritative-Domain-Sender welke ervoor zorgt dat elke sessie welke verzonden wordt vanaf een domein wat geconfigureerd staat als authoritative domain niet gecontroleerd wordt.
Om dit te voorkomen dien je de rechten te verwijderen middels onderstaande command:
Get-ReceiveConnector “Internet” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission
Let wel op dat wanneer je deze regel hebt verwijderd van de connector eventuele andere internet applicaties/apparatuur hier geen gebruik meer van kan maken. Voor deze applicaties/apparatuur dient dan een aparte receive connector aangemaakt te worden.
Gepost in Exchange 2007 ~ Geen Reactie
Microsoft Exchange couldn’t start transport agents. The Microsoft Exchange Transport service will be stopped. Dat is een van de meldingen die je kunt krijgen als er een transport agent corrupt is. Dit kan echter tot gevolg hebben dat de transport service niet meer start zoals in het voorgaande voorbeeld wat weer tot gevolg heeft dat er geen mailverkeer meer mogelijk is.
Er zijn twee oplossing voor dit probleem:
- verwijderen van de transport agent
- uitschakelen van de transport agent
De eerste methode is misschien wel het beste waarom zou je immers een corrupte agent op je systeem willen hebben. Je kunt de agent verwijderen middels het Powershell commando:
Uninstall-TransportAgent “Naam van de Agent”
Mocht je toch nader onderzoek willen doen en de agent uitschakelen, dan kan dit door het volgende Powershell commando uit te voeren:
Disable-TransportAgent -Identity “Naam van de Agent”
Wanneer het probleem weer is verholpen kun je de agent weer inschakelen met het volgende commando:
Enable-TransportAgent -Identity “Naam van de Agent”
Wil je naar aanleiding van bovenstaande meer informatie willen hebben over de commando’s neem dan eens een kijkje op onderstaande site:
Technet: Transport Agent Cmdlets open
Gepost in Exchange ~ Geen Reactie
Met de komst van Exchange 2010 kan het weleens een leuke vergelijking zijn om te kijken wat eigenlijk de huidige effectiviteit van Single Instance Storage is op je huidige databases. Het is natuurlijk altijd handig om te weten wat er zou gaan gebeuren als je geen gebruik meer maakt van Single Instance Storage, zoals in Exchange 2010 het geval is.
De meting kan uitgevoerd worden met de counters die toegevoegd worden tijdens de Exchange installatie, je kunt ze vinden in de Performance Monitor onder:
- MsExchangeIS mailbox
- MsExchangeIS public
Onder deze twee objecten zul je Single Instance Ratio counter terugvinden. Voeg deze toe aan perfmon en hou de grafiek een tijdje in de gaten of sla het uiteraard op in een log bestand en bekijk het later.
Gepost in Exchange ~ Geen Reactie
Zoals je misschien weet doet Exchange een discovery om zo de domain controllers te vinden in de AD. Wanneer je in het application event log zal kijken zul je events zien met als bron MsExchange ADAccess en als Event id 2080. Dit event zal ongeveer om de 15 minuten te zien zijn aangezien deze check elke 15 minuten uitgevoerd wordt.
Het event kan bijvoorbeeld onderstaande data bevatten:
Event Type: Information
Event Source: MSExchangeDSAccess
Event Category: Topology
Event ID: 2080
Computer: Ex01
Description:
Process MAD.EXE (PID=1808). DSAccess has discovered the following servers with the following characteristics:
(Server name | Roles | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
dc01.domain.com CDG 7 7 1 0 0 1 7 1
dc02.domain.com CDG 7 7 1 0 1 1 7 1
Out-of-site:
For more information, click http://search.support.microsoft.com/search/?adv=1.
Leuk al die afkortingen en nummers maar wat betekenen ze nou eigenlijk:
- servername, de eerste kolom bevat de servernaam van de betreffende domain controller
- roles, welke rollen vervult de domain controller: C de domaincontroller wordt gebruikt als configuration domaincontroller, D een domain controller en G de domain controller is ook een global catalog server. Wanneer je hier nu een – ziet dan betekent dit dat de server deze rol niet kan vervullen
- reachability, elke kwartier wordt er connectie met de server gemaakt. Wanneer een server de global catalog server rol vervult zal geprobeerd worden te connecteren op poort 3268, wanneer dit lukt zal de waarde 0×1 worden weergeven. Wanneer er op poort 389 connectie gemaakt kan worden betekend dit dat de server ook een domain controller is, de waarde zal dan 0×2 zijn. Wanneer een server een configuration domain controller is zal wederom een connectie worden opgezet naar poort 389. Lukt dit dan zal de waarde 0×4 worden weergeven. Vervult een server nu meerdere rollen zoals in het voorbeeld dan worden de waarden bij elkaar opgeteld. Als de server dus alle 3 de rollen vervult dan is dit 0×1+0×2+0×4=0×7 en zal 7 worden weergeven.
- synchronized, wanneer de isSynchronizedflag is gezet op de rootDSE van de domain controller dan zal deze waarde op waar staan. De waarde wordt net als bij de kolom reachability bepaald per rol.
- GC capable, is de domain controller ook een Global Catalog Server
- PDC, is de domain controller ook een PDC voor het domein
- SACL right, zijn de rechten correct voor DSAccess om de SACL uit te lezen
- Critical Data, geeft aan of DSAccess de Exchange server heeft kunnen vinden in de configuratie partitie van de domain controller.
- Netlogon Check, kan er connectie gemaakt worden naar de netlogon service van de domain controller
- OS version, indien deze waarde op 1 staat wil dit zeggen dat de domain controller minimaal Windows 2000 Service Pack 3 als OS heeft.
Nou kan het natuurlijk voorkomen dat je liever niet hebt dat Exchange een domain controller gebruikt. De vraag is alleen hoe kun je dit configureren ?
Dit kun je doen door het commando: set-exchangeserver -identity exchange.domain.com -StaticExcludedDomainControllers dc.domain.com te gebruiken.
Wil je nu het liefst zelf de configuration domain controller, domain controller en global catalog server opgeven dan kun je dit doen door het volgende commando uit te voeren: set-exchangeserver -identity exhange.domain.com -StaticConfigDomainController dc01.domain.com -StaticDomainController dc01.domain.com,dc02.domain.com -StaticGlobalCatalogs dc01.domain.com
Technet set-exchangeserver open
Gepost in Exchange ~ Geen Reactie
DNS records en Exchange, het is niet zo heel moeilijk maar wel heel erg belangrijk dat ze goed zijn ingesteld. Verkeerde DNS records en dan vooral pointer records kunnen ertoe leiden dat mail wordt geweigerd.
Welke records zijn er nodig voor het verzenden en ontvangen van mail met Exchange:
A-record, dit record zorgt ervoor dat een naam omgezet kan worden in een ip-adres, bijvoorbeeld mail.domain.com
PTR-record, dit record wordt gebruikt voor een reverse lookup. Door een query te doen naar het ip-adres en te controleren of dit naar de naam verwijst waarvan de mail afkomstig is (het A-record) kan bepaald worden of de mail echt afkomstig is van de betreffende mailserver.
MX-record, van dit type record kunnen er meerdere aanwezig zijn. Elke entry is aan mailserver waaraan de mail afgeleverd kan worden. Elke regel heeft een prioriteit, afhankelijk van de prioriteit wordt het bericht aangeboden aan de mailserver. Stel je hebt 2 records een met een prioriteit van 10 en de ander van 99. Dan zal de verzendende mailserver eerst proberen de mail af te leveren bij de mailserver met prioriteit 10 en indien deze niet beschikbaar is de mailserver met prioriteit 99.
SPF-record, dit type record is optioneel. Dit record bevat alle namen/ip-adressen van servers welke mail namens het betreffende domein mogen verzenden en ontvangen. Als ontvangende partij kun je dit dus gebruiken om te controleren of de mail echt wel afkomstig is van een mailserver van het verzendende domein.
Naast de DNS-records voor verzenden en ontvangen dienen er ook DNS records aangemaakt te worden om autodiscover te laten werken:
A-record, dit record zorgt net als het A-record voor verzenden en ontvangen dat een naamomgezet kan worden in een ip-adres, in het geval van autodiscover dient dit de volgende syntax te zijn: autodiscover.domain.com
SRV-record, dit record kan i.p.v. het A-record gebruikt worden om de autodiscover service beschikbaar te maken voor gebruikers van Outlook 2007. Dit record bevat de naam van de CAS-server welke de gebruiker gebruikt om connectie te maken met Exchange. Een voorwaarde om deze manier te gebruiken is dat elk A-record of C-Name verwijdert wordt.
Voor dit alles bestaan natuurlijk een aantal handige tools, onderstaand een overzicht van tools welke ik vaak zelf gebruik:
EmailTalk, site met diverse tools om bijvoorbeeld: ptr, mx of spf record te controleren open
MXtoolbox, site met diverse tools om bijvoorbeeld: mx record te controleren, te controleren of je op een RBL staat en je mailserver vanaf extern te testen open
Microsoft SPF Record Wizard, site welke je helpt om een SPF record te maken open
Gepost in Exchange ~ 5 Reacties
