MOLEHAND Solutions

 
Print  
Author: MOLEHAND Created: 2008. 09. 26. 23:33
Exchange

By Molnár Péter on 2011. 06. 28. 15:18

Ha nincs Edge Transport Server, akkor a Hub Transport alatt fogjuk megtalálni miután futtattuk a exchange shellben:
 
C:\"Program Files"\Microsoft\Exchange Server\V14\Scripts\install-AntispamAgents.ps1 scriptet.
 
Majd shellből Restart-Service MSExchangeTransport vagy services mmc ből restart és megtaláljuk a EMC ban a hiányzó beállításokat.
 

By Molnár Péter on 2011. 02. 25. 16:52

Ha végképp elakadtunk a Public Folder eltávolítással (pl. szerver unintall esetén) Akkor ez a megoldás biztosan segít: ADSI edit > Configuration > Services > Microsoft Exchange > First Organization > Administration Groups > Exchange Administrative Group > Servers > szervernév > Information Store -on belül töröljük az érintett Public Folder Database CN-t.
 
(Ha marad PF adatbázis a rendszerben azt ne töröljük, és ellenőrizzük átkerült-e rá minden szükséges tartalom)

By Molnár Péter on 2011. 02. 24. 0:07

Az SPF segítségével a DNS-ben beállíthatjuk, melyik szerverek jogosultak e-mail küldeni az adott domainről. Kis segítség a beállításhoz:
Lekérdezéshez:

By Molnár Péter on 2010. 09. 21. 12:20

Ha egy distribution group nevében akarunk levelet küldeni azt az ADUC-ban állíthatjuk be:
- Ellenőrizzük, hogy az Advanced Features megjelenítése be van állítva
- A csoport tulajdonságai között válasszuk a Security-t.
- Adjuk hozzá a kívánt felhasználókat és állítsuk be nekik a SendAs jogot

By Molnár Péter on 2010. 06. 04. 1:46

Az Exchange alapvetően két típusba sorolja a domaineket:
- Saját domainek
- Távoli domainek
 
A második csoport alértelmezetten *, azaz minden domainra vonatkozik. Azonkívül, hogy itt korlátozhatjuk a a domaineket, amikre küldhetnek a felhasználók. A távoli domainek viselkedését is itt szabhatjuk meg.
Ezek közül leginkább figyelemre méltó az automati válasz és továbbítás engedélyezése vagy tiltása. Ráadásul ez a * domainre alapesetben nincs is engedélyezve.
Tehát ha a felhasználók arra panaszkodnak, hogy nem működnek bizonyos szabályok az outlookban, ezt is ellenőrizzük!

By Molnár Péter on 2010. 06. 01. 16:45

A 2010-es Exchange bizonyos körülmények között hiányosan telepíti fel az IIS Role service-ekt, emiatt nem működnek az IIS alapú szolgáltatások (OWA, OMA, RPCoverHTTP, ECP, ActiveSync).
Maguk a site-ok működnek, de az aothentikáció nem történik meg. (Form esetén hibás felhasználói név/jelszó hiba).
 
A javításhoz telepíteni kell a Basic és Windows authentikációt az IIS Role service közé (Illetve ha van egyéb autentikációra szükség, akkor azokat is)

By Molnár Péter on 2010. 03. 20. 2:59

A jó bevált hMailServer melett, kijött a MailEnable 4-es verziója, ami webmailt-t is tartalmaz. Tehát vannak ingyenes alternatívák az Exchange mellett.
A MailServer 5 mélyebb funkciókkal bír (SPAM szűrés, Antivirus, IMAP), ezzel a szemben a MailEnable komplexebb megoldás minden alapszolgáltatással (Webmail, Lists), ráadásul későbbiekben bővíthető, így érdemes választás kisvállalatok sját levelezőszerverének.
 

By Gömbös Attila on 2010. 02. 22. 13:10

Mint az előző cikkben említettem az Outlook rengeteg Exchange szolgáltatást HTTP-n keresztül használ függetlenül a csatlakozás módjától. Ezért fokozottan fontos HTTPS esetén a megfelelő tanúsítványok használata.
 
Az különböző Exchange szolgáltatások azonban különböző címeken érhetőek el (pl.: autodiscover.molehand.eu, owa.molehand.eu). Továbbá MAPI RPC-n való közvetlen csatlakozáskor a belső címek is teret kapnak (mhxch, mhxch.mh.local). Az Exchange 2007 a kapcsolódás helyétől függetlenül mindig ugyanazt a tanúsítványt küldi a kliensnek. Kizárólag külső csatlakozás esetében ez egy wildcard nevet (*.molehand.eu) felhasználva a tanúsítványban megoldható lenne a probléma. Azonban ha belső hálózatról is kommunikálunk RPCoHTTP nélkül a szerverrel, akkor több host nevet is el kell helyeznünk a tanúsítványban. Erre ad lehetőséget a Subject Alternative Name (SAN) mező a tanúsítványokban.
 
A SAN támogatása sajnos nem teljes - nem támogatja az ISA 2006 SP1 nélkül, több tanúsítványkiadó szervezet se, és az OpenSSL régi verziói se.
 
SAN tanúsítvány kiadása/megújítása és beállítása Exchange 2007-en és ISA 2006 SP1-en:

1. Állítsuk elő a certificate requestet az EMS-ben:

New-ExchangeCertificate -DomainName *.molehand.eu, mhxch, mhxch.mh.local -IncludeAcceptedDomains -FriendlyName "*.molehand.eu" -IncludeAutoDiscover -GenerateRequest:$True -Keysize 2048 -path c:\certreq.txt -privatekeyExportable:$true -subjectName "c=HU, O=Molehand Ltd., OU=Solutions, L=Budapest, CN=*.molehand.eu"

DomainName paraméterben felsoroljuk a külső és belső címeket. Az IncludeAcceptedDomains, és IncludeAutoDiscover paraméterek miatt az EMS automatikusan kiegészíti további alternatív nevekkel a tanúsítványt ha szükséges. Mivel ISA szerverre is szeretnénk importálni a tanúsítványt, ezért a PrivateKeyExportable legyen true.

2. A certsrv segítségével adjuk ki a requestnek megfelelő tanúsítványt. Az eredmény egy p7b kiterjesztésű fájl lesz, ami nem tartalmazza a privát kulcsot, tehát ez nem importálható az ISA szerverre.

3. A privát kulccsal rendelkező tanúsítvány megszerzéséhez először importálnunk kell a tanúsítványt az Exchange szerverre:

Import-ExchangeCertificate –Path c:\mhxch.p7b | Enable-ExchangeCertificate –Services IIS, POP, IMAP

4. Ezekután az Exchange szerveren a Certificates MMC Local Computer - Personal tárolójából exportálhatjuk .pfx kiterjesztéssel a privát kulcsot tartalmazó tanúsítványt.

5. A .pfx kiterjesztésű tanúsítványt importáljuk az ISA szerveren a Certificates MMC Local Computer - Personal tárolójába.

6. Az ISA szerveren a megfelelő HTTPS listener Certificates fülén kiválaszthatjuk az új tanúsítványt.

Bővebb információk, de 3rd party tanúsítványkibocsátót használva:

http://www.msexchange.org/articles_tutorials/exchange-server-2007/mobility-client-access/securing-exchange-2007-client-access-server-3rd-party-san-certificate.html

By Nagy Balázs on 2010. 01. 01. 21:26

Ha már van telepítve 2007-es Cliens Access Server de mellette a 2010 -es tartozót is feltelepítjük akkor az Exchange Management Console 2010-ben egy hiba fogad minket amikor  a CAS -t szeretnénk konfigurálni.
Hibaüzenet:
An IIS directory entry couldn’t be created. The error message is Access is denied. HResult = –2147024891
A probléma forrása az, hogy a 2007-es CAS nem engedélyezi hogy a 2010 -es CAS hozzáférjen az IIS-hez.
 
Megoldás: az AD-ban megtalálható "Exchange Trusted Subsystem" csoportot hozzá kell adni a XCH2007-en futattó szerver Administrator csoportjához.

By Kiss Tamás on 2009. 11. 23. 15:39

Exchange Management Shell :
 
Konkrét e-mail címekre:
 
1. $list = (get-ContentFilterConfig).BypassedSenders
2. $list
3. $list.add("valaki@domain.com")
4. set-ContentFilterConfig -BypassedSenders $list
 
Domainre:
 
Ugyan ez, csak BypassedSenderDomains -nek adunk értéket.
Ilyenkor használhatjuk a *.example.com formát, így az összes subdomainre engedélyezzük a contentfilter kikapcsolását. 
 
 

 

Discount offer

 I’ve already tried several providers. Currently all of our projects are placed at MOLEHAND, because they provide real services not only a piece of a computer. Any kind of new problem crops up, I can always count on a fast and expert reaction.