- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- Csatába küldte Magyarországon idei csúcs hangprojektoros szettjét a Samsung
- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- VR topik (Oculus Rift, stb.)
- Háromféle processzor is része lesz a Core 200 sorozatnak
- Dell notebook topic
- A régi node-okra koncentrál a szankciók miatt Kína
- ThinkPad (NEM IdeaPad)
- Csatába küldte Magyarországon idei csúcs hangprojektoros szettjét a Samsung
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
Hirdetés
-
Újabb Samsungok telepíthetik a Galaxy AI-t
ma A Galaxy S22 és S21 család is One UI 6.1-re vált, ám eltérő AI funkciókkal.
-
A legtöbb amerikai szerint a TikTok egy őket befolyásoló eszköz
it Egy felmérés szerint a legtöbb amerikai osztja azon véleményt, hogy a TikTok egy őket befolyásoló eszköz.
-
A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
ph A vállalat többek között egy slim profilos léghűtővel, egy helytakarékos táppal és egy ITX-es házzal adott magáról életjelet.
Új hozzászólás Aktív témák
-
brd
nagyúr
Exchange 2003 esetén van valami hasonló megoldás, mint pl. ami AD esetén működik, hogy egy másik gépre folyamatosan replikálódnak az adatok, így ha az egyik kiesik, a másikról ugyanúgy működik tovább a domain?
The only real valuable thing is intuition.
-
brd
nagyúr
Üdv. néktek' szakik!
A felállás: Exchange 2003 Ent. SP2, ASSP spamfilter, méretkorlát az internet-szolgáltató mailserverén.
Az ASSP tanítása ugye úgy működik, hogy egy bizonyos e-mail címre kell továbbítani a spam-nek minősülő, ill. egy másikra a spam-nek minősített, de nem spam e-mail-t. Emiatt az Exchange-ben smart host-nak az ASSP van beállítva, amelyben pedig smart host-nak az internet-szolgáltató mailservere. Ez így eddig remekül működött, azonban az internet-szolgáltató úgy gondolta, hogy 5 MB-nál nagyobb e-mail-t nem lehet a továbbiakban küldeni. Ezért szeretném azt megoldani, hogy az Exchange maga küldje a leveleket szerte a világba. Ha ugye simán átállítom, hogy ne az ASSP-re állított smart host-on keresztül küldje, akkor az ASSP-t nem lehet tanítani; az ASSP pedig nem képes maga, DNS alapján route-olva küldeni a leveleket (legalábbis, nem találtam benne ilyen beállítást).
Tehát valami olyan megoldás kellene, hogy az ASSP visszaküldje az Exchange-nek a kiküldött leveleket, ami aztán továbbnyomja. Lehet ilyet? Hogyan?The only real valuable thing is intuition.
-
brd
nagyúr
A t-online mail serverén keresztül csak authentikációval tudsz küldeni. Saját maga a servered talán azért nem tud küldeni, mert a 25-ös port forgalmát a t-online tiltja. Ha így van, külön lehet kérni, hogy engedélyezzék. A microsoft.com mail exchanger-e pedig nem az általad próbált címen figyel, hanem az alábbi paranccsal tudod lekérdezni:
nslookup -querytype=mx microsoft.com
Persze a kapott cím, a mai trendeknek megfelelően csak akkor válaszol a 25-ös porton, ha a cím, ahonnan próbálod, maga is rendelkezik megfelelő mx record-dal (és/vagy nincs benne egy bizonyos adatbázisban, vagy épp az, ha benne van, ez most részletkérdés ); ez egyúttal egy tesztnek is megfelel.The only real valuable thing is intuition.
-
brd
nagyúr
Van egy fura gondom egy Ex2003-mal: nem igazán hajlandó több memóriát lefoglalni, mint kb. 600 MB (a store.exe). A win az 2003 Standard (SP2), az Ex az Enterprise (szintén SP2), 3 GB memória van a gépben, és ez a DC is egyben. A boot.ini-ben be van állítva a /3gb kapcsoló (mellé egy /userva=3000 is, a biztonság kedvéért), és életbe is lépett, a testlimit.exe kb. 2980 MB-nyi virtuális címet tud lefoglalni. Az Ex-et kb. 25 user használja, ebből 2-3-nak több GB-os postafiókja van, a teljes adatbázisok mérete kb. 57 GB (34 GB Mailbox, 23 GB Public). A HeapDeCommitFreeBlockThreshold és a msExchESEParamCacheSizeMax értékei a M$ ajánlásai alapján van beállítva. Ami talán lényeges lehet: fut még egy kisebb SQL (SQL 2000 Standard) adatbázis is a serveren, de alig van használva, talán ha 40-50 MB-ot eszik az sqlserv.exe; ill. itt fut a SPAM-filter is (ASSP; a perl.exe kb. 80-90 MB-ot foglal). A taskmanager szerint az össz' foglalt memória kb. 1.5 GB, és a system cache kb. 1.5 GB-nál jár. Ez utóbbit (egy tetemes részét legalábbis) szeretném, ha az Ex zabálná meg. A server kb. 1 hete fut (a store.exe is), próbálgattam nagyobb public mappákba bemászkálni, a nagyobb leveleket nyitogatni, de így is max. 600 MB-ot hajlandó lefoglalni. Van valakinek ötlete, hogy mit lehetne még tenni?
The only real valuable thing is intuition.
-
brd
nagyúr
Köszi, de én is ezt linkeltem. Az ESE buffer a max. javasoltra van állítva a doksi alapján. Az SQL sosem evett még 100 MB-nál többet, még virtuális címet sem foglalt annyit (de mivel Standard, amúgy is max. 2 GB-ot tudna, tehát a 3 GB fizikai RAM-ból még akkor is maradna az Exchange-nek, ha mindet elfoglalná). Mindenesetre leállítom 1-2 napra az SQL-t, hátha, de nem hiszem, hogy számítana.
The only real valuable thing is intuition.
-
brd
nagyúr
Megoldva, működik rendesen, nézegettem a perfmon-ban a Store exe Virtual Bytes-t és a teljes mentésnél felszalad rendesen kb. 2,5 GB-ra a foglaltság. Úgy tűnik, többnyire kevésnek ítéli a terhelést az Exchange normál üzemben. Egyszerűen ilyen kis takarékos a memóriával.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz Panthera #202 üzenetére
Nem. Ill. igen, mert maga az Exchange az AD-re/be épül rá/be, de szerintem te azt akarod tudni, hogy a gépnek, ahonnan bejelentkezel az Exchange-re, annak kell-e domainben lennie.
Vagy arra gondolsz, hogy másik domainben létező felhasználónak akarsz postafiókot csinálni?[ Szerkesztve ]
The only real valuable thing is intuition.
-
brd
nagyúr
válasz kraftxld #207 üzenetére
Azért IMAP-képes levelező használatával is működik (legyen ez akár Outlook Express), persze bizonyos dolgokról le kell mondani, ami Outlookspecifikus, pl. Naptár, találkozók szervezése, Feladatok, továbbá a címlista sem lesz elérhető (mondjuk az AD-ből lehet keresni címzettet). De a sima levelezésre teljesen jól működik, ha nagyon nincs Outlook.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz Panthera #211 üzenetére
Igen, ha az Exchange-en be van állítva az IMAP elérés rendesen, akkor bármilyen, IMAP-képes levelezővel tudod használni, eléred az összes mappát, de az összes elem is sima levélnek fog látszódni (amiket írtam példát, tulajdonképpen az összes, csoportmunka/Outlook-specifikus elem), de levelezni lehet vele. Bár az Outlook Express IMAP-kezelésétől nem vagyok elájulva, kissé nyögvenyelős. Mindenesetre működik.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz Panthera #259 üzenetére
Ha AVG van a kliensen, akkor próbáld meg lelőni benne a Link Scannert és a Web Shield-et, nekem okozott már gondot, igaz, nem Exchange vonatkozásában, hanem SQL esetén (igen, és is szájtátva bámultam, hogy mi köze hozzá, de ez van), de egy próbát megér.
The only real valuable thing is intuition.
-
brd
nagyúr
Ha magyar SBS-ről van szó, akkor elsőként arra hívnám fel a figyelmed, hogy egy registry kulccsal bajod lesz (valamilyen javítócsomag verzió rémlik, hogy azt nem fogja találni), ezt mindenképpen kézzel kell majd módosítani (létrehozni), mert nem tudsz továbblépni (azóta lehet, hogy javították az újabb 2008-ban). Ha jól emlékszem, ezzel kapcsolatban a SBS Best Practice Analyzer is, és a migrálóvarázsló is pontosan kiírja, hogy mi a baja. Egyebekben a SBS_Migration.doc teljesen jól használható. Ha Premium volt a 2003-as SBS, akkor azt is tudnod kell, hogy az SQL szolgáltatást is neked kell áthekkelni (ez sem túl bonyolult egyébként), figyelembe véve, hogy a Server 2008-cal egy időben 2008-as SQL-re kell átállni (a 2005 csak átmeneti megoldás, a kompatibilitás miatt került csak bele, mint lehetőség). No' és persze ISA sem lesz a 2008-ban. Az Exchange-es részéhez nem tudok hozzászólni, sosem használtak ott ilyen levelezést, ahol ilyen migrálást csináltam, de nem hiszem, hogy más lenne, mint domain-en belül, 2 server között, egy nem SBS-es Exchange migrálás; erre pedig pl. ezt a sorozatot olvasgathatod.
Hmm... mi van még, ami gond lehet...? Talán a filemegosztások. Mivel a server neve, és IP-címe kötelezően meg kell változzon, ezért ha nem DFS segítségével voltak megosztva a cuccok, akkor ezt is át kell valahogyan írogatni a klienseken, ez biztos egyértelmű, csak mondom, hogy oda kell rá figyelni, mert ez is idő.
A 21 nap egyébként nem kevés szerintem. Gyakorlatilag csak hétvégén tudtam több helyen ilyennel foglalkozni (hétköznap dolgoztak), de max. 3 hétvégéből (az meg ugye 16 nap, és ha nagy baj van, még mindig van 5 napod) mindig letudtam, de többnyire inkább 2 volt, ez is csak a sok adat, vagy a nagy SQL adatbázis miatt (meg hogy ugye vasárnap este úgy kellett otthagynom, hogy lehessen ugyanúgy dolgozni a rendszerrel, mint előtte), tehát lényegében a 2. nap végére már az új server-ről működött szinte az összes szolgáltatás, úgy, hogy a 2008 telepítését is helyben csináltam, beadagolva neki a válaszfile-t. Persze ez elsőre nem biztos, hogy ilyen simán fog menni, inkább azt mondanám, hogy 3-4 nap lesz, ha nem dolgoznának vele közben.
A legfontosabb: mielőtt bármit csinálsz, mentsd le a 2003-at (legalább egy System State, de inkább teljes backup), mert ha elindítottad a varázslást, nincs visszaút, csak ha backup-ból teszed vissza a 2003-at (le fog álldogálni a 2003, a 21 nap elteltével).The only real valuable thing is intuition.
-
brd
nagyúr
Ilyenkor általában az szokott lenni a probléma, hogy egy olyan felhasználóval próbálja a kliens, amelynek egyébként van joga elérni a könyvtárat, de a helyi gépen más a jelszava, mint a megosztóoldalon. Pl. mindkét oldalon van rendszergazda, de más jelszóval. Ilyenkor nem kér felhasználónevet, mert azt látja, hogy a helyi gépen is van ilyen, viszont azt már nem tudja feldolgozni, hogy más a jelszava, és ezért azt írja, hogy nincs joga. Ez a megosztóoldalon, az eseménynaplóból (Biztonság/Security) kiderül, ha logoltatod a sikertelen bejelentkezéseket.
Egyébként ez a kérdés mit keres az Exchange topicban?The only real valuable thing is intuition.
-
brd
nagyúr
Valakinek van ötlete, hogy hogyan lehet lebeszélni a 2007-es Ex' HTS-ét arról (nincs Edge, és súlyosbító körülmény, hogy SBS), hogy ha smart host-on keresztül kellene tolnia kifelé a leveleket, akkor ott már ne próbálkozzon MX lekérdezéssel? Simán be kellene telnetelnie a smart hostra, ehelyett lekérdezi a smart host MX rekordját, és oda akar kapcsolódni. WTF? Vajon mit szívhatnak az Ex'-es fiúk? Kérnék én is belőle asszem'. (Persze ha a smart host IP-jét írom be az FQDN helyett, akkor megfelelően működik, csak így ha változik az IP, akkor lehet átírni...). Esetleg valami speciális formában kell beírni az FQDN-t? Mondjuk B@m@g%#mail.isp.net#%@, amit sehol sem írnak le?
A másik kérdésem az lenne, hogy ennek a viselkedésnek mi értelme? Vagy ez egy oltári nagy bug lehet?The only real valuable thing is intuition.
-
brd
nagyúr
válasz kraftxld #590 üzenetére
Utóbbi, de aztán rájöttem, hogy SBS, és inkább visszaállítottam a kiindulási állapotot, mielőtt magába zuhan, és később majd szívhatok vele (most az SBS konzolban minden ződ', és a smart hostot is ott állítottam aztán be). A send connector, ill. a transportserver beállításai között mindenesetre nem találtam erre vonatkozó opciót (EMS-ben sem), tehát még ha baj is lett volna a nekiesés, akkor sem látom, hol lehetne rosszul beállítani.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz kraftxld #592 üzenetére
Megy(menne) is, csak valamiért az ISP-nél olyan MX rekordok vannak beállítva a smart hosthoz, ahol nem tud authentikálni a smart host-hoz megadott credentials használatával. Ez máshol (sok helyen) valószínűleg nem így van, ezért nem okoz gondot általában.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz kraftxld #596 üzenetére
Igen, a legtöbb (pontosabban eddig mindenhová) helyre itt is, viszont ha *@invitel.hu címre küldetnék így (DNS/MX alapján) levelet, akkor azt írja a serverük, hogy:
z.mx.invitel.net #554 5.7.1 <x.x.x.x.static.invitel.hu[x.x.x.x]>: Client host rejected: You have mass IP pool like reverse in DNS, fix it or use smtp relay from your provider. ##
(Mint látszik, fix IP van.)
Erre a szolgáltató azt mondta, hogy állítsam be smart hostnak a mail.invitel.hu-t, mert csak úgy engedélyezik a küldést. A vége az lesz, hogy az invitel.hu-hoz gyártok egy külön send connectort, látom már...[ Szerkesztve ]
The only real valuable thing is intuition.
-
brd
nagyúr
Elolvastad rendesen a hozzászólást?
Nem jó, én nem szeretem, hogy kell smart host, nem akarom, hogy egy másik gárda hozzáértésétől függjön a levelezés, de bizonyos helyekre (eddig konkrétan egyet találtam a jelen eset vonatkozásában) egy adott módon lehet csak levelet küldeni.
Hogy minek? Ott a példa.#599: Az Exchange kifelé NAT-olva jut ki, szal' a címe biztos nem okoz gondot, a külső IP-hez pedig van PTR. Vagy arra gondolsz, hogy az első Received sorban van belső hálós IP/gépnév?
The only real valuable thing is intuition.
-
brd
nagyúr
válasz macimeister #602 üzenetére
Csak az adott felhasználónál, vagy mindenkinél? Felhasználó, vagy public folder? Az ADUC-ban Properties a felhasználón, Exchange Feautres. Public Folder esetén magán a Public Folder Store-on is be tudsz ilyet állítani, ill. külön folderenként is. De lehet még a Connectorokon és a SMTP Virtual Servereken is méretkorlátot beállítani, továbbá az ESM-ben a Global Settings alatt is van méretkorlátozási beállítás. Ha jól emlékszem, máshol nincs.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz kraftxld #604 üzenetére
A messageSizeLimit-re gondolsz? (Bár az alapból nincs beállítva, azonkívül erről a beállításról leírás sem nagyon van szerintem - az RGC vonatkozásában legalábbis -, mert van másik, a grafikus felületre is kivezetett méretkorlát-beállítási lehetőség a connectorokon, és inkább azt javasolják, így nem valószínű, hogy ott lenne beállítva.)
The only real valuable thing is intuition.
-
brd
nagyúr
Az internetszolgáltatót kell megkérni, hogy adjon ilyet. De valószínűleg van most is. Mindenesetre, ha majd lesz (vagy már most is van) Reverse DNS (pl. itt is meg tudod nézni, ha a parancssor annyira nem a haverod ), akkor ezt ajánlom olvasásra. A megoldás az lett, hogy a *.invitel.hu és *.invitel.net domainekhez készítettem egy Send Connectort, ez a mail.invitel.net smart hoston keresztül küldi a leveleket, a szolgáltató által megadott credentials használatával.
The only real valuable thing is intuition.
-
brd
nagyúr
A management process (online defrag) le tud futni? Nincs az időzítése idejére valami másik folyamat időzítve, pl. indexelés, vagy backup? Mert akkor szemérmesen háttérbe vonul, és esetleg emiatt sosem tud lefutni.
Ill. nem az a helyzet, hogy be van állítva, permanensen ne törlődjenek az elemek az adatbázis mentéséig, és mentés meg nincs, így sosem törlődnek?The only real valuable thing is intuition.
-
brd
nagyúr
válasz desolator #1272 üzenetére
Igen, mert nem fut le az Exchange adatbázis mentése sikeresen. Csak akkor törlődnek a logok. Vagy esetleg beállíthatsz körkörös logolást (circular logging), akkor nem eszi meg a helyet, de azt inkább ne, ha ilyen gondok vannak, hogy nem ismeri fel a felelős, hogy hibás a mentés (vagy nincs is felelőse...?), mert talán jó mentés még soha sem készült, vagy nincs már meg. A logolásnak egyébként az az értelme, hogy ha megsérül az adatbázis, akkor az utolsó jó(!) mentés, és a tranzakciós logok segítségével vissza lehet állítani a mentés, és a sérülés közötti tartalmat is.
[ Szerkesztve ]
The only real valuable thing is intuition.
-
brd
nagyúr
válasz deminos #1298 üzenetére
A SMTP Virtual Serveren nézd meg, hogy nincs-e véletlenül a Windows Integrated authentikáció bekapcsolva, mert az okozhat ilyen hibát (nyilván csak ott kapcsold ki, ahol nincsen rá szükség): properties/delivery tab/outbound security és ott windows integrated; vagy ugyanez esetleg a Connectoron: properties/advanced tab/outbound security.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz ielektros #1343 üzenetére
Nagyon ne küzdj vele, dinamikus IP-n nem fogsz mail servert üzemeltetni, legalábbis olyat, ami fogadni is kell tudjon tetszőleges időben. (Pontosabban lehet, de ahhoz olyan DNS szolgáltatás kell, ami egyrészt rövid időn belül automatikusan - a változott IP hatására - át tudja állítani a hostot, másrészt az MX-bejegyzés TTL-je megfelelően rövid is lehet, de még ekkor sem lesz teljesen problémamentes.)
The only real valuable thing is intuition.
-
brd
nagyúr
válasz ielektros #1345 üzenetére
A havonta az már használható, ha együtt tudtok élni a minimum TTL-nyi idejű levélfogadás-kieséssel (addig van ugye cache-elve, és ehhez még hozzájön az IP váltás, és a DNS bejegyzés átállítása közötti idő). Akkor sem lesz új IP, ha újracsatlakozik az eszköz?
Hogy milyen megoldást? Fix IP-t kell rendelni.The only real valuable thing is intuition.
-
brd
nagyúr
válasz ielektros #1347 üzenetére
Az e-mail fogadáshoz kell ugye egy ún. MX record, ezt a domain DNS opciói között lehet beállítani, de ez egy IP-re kell mutasson (pontosabban ma már az a javasolt, hogy egy "A" recordra, és az egy IP-re). Az a probléma, hogy ennek van egy ún. TTL-je, ennyi ideig van cache-elve más DNS servereken, így egy külső gép, ami levelet akar küldeni a te domain-edre, az lekérdezi az MX recordjait (és az aldomain "A" recordját) a domainnek, és megkapja a cache-elt változatot, ami legfeljebb egy TTL-nyivel régebbi információ lesz (ha közben változik az IP, akkor ugye ez rossz helyre fog mutatni). Ez a TTL ma olyan 1-4 óra szokott lenni, és a DNS server kezelője határozza meg. Ezt az "A" record kellene frissítgetni valahogyan, amikor változik a külső IP. Ha olyan a domain-ed, akkor ezt automatikussá is lehet tenni (pl. dyndns, vagy no-ip.org, náluk ráadásul a TTL is lehet valami fél perc, ha jól emlékszem). Így nagyjából működni fog, csak IP váltáskor lesz egy kis TTL időtartam körüli kiesés, ill. ha a régi IP-t valami más által üzemeltetett mailserver kapja meg (vagy olyan szolgáltatás, ami elhajtja a küldő servert a megfelelő hibával), akkor egyes levelek vissza is pattanhatnak.
The only real valuable thing is intuition.
-
brd
nagyúr
válasz jaszy91 #1358 üzenetére
Ha a DNS kezelőben nem találsz SPF néven futó rekordtípust, akkor TXT-t vegyél fel. Először próbáld meg a levelezőserver IP-jét hozzáadni jól, aztán próbálkozhatsz finomabb beállítással. Pl. valahogyan így kell kinéznie: IN TXT "v=spf1 ip4:15.15.15.15/32 -all" Ezzel azt mondod meg, hogy a 15.15.15.15-ös IP jogosult levelet küldeni az adott domain-nel végződő címekről. Az SPF hiánya egyébként nem minősül hibának, emiatt levelet nem igazán szoktak elutasítani. A logban milyen hibaüzenetet találsz, mit ír vissza a túloldali server?
The only real valuable thing is intuition.