XFOR: GroupWise Architecture (část 2): řízení toku a glosář

Překlady článku Překlady článku
ID článku: 254346 - Produkty, které se vztahují k tomuto článku.
Tento článek byl archivován. Je nabízen v takovém stavu, v jakém je, a nebude již nadále aktualizován.
Rozbalit všechny záložky | Minimalizovat všechny záložky

Souhrn

Tento článek znalostní báze Knowledge Base je sekunda v řadě tři články znalostní báze Knowledge Base poskytují souhrn základní architektura Novell GroupWise 5.5. Tento článek popisuje tok GroupWise zprávy a nabízí metody řešení potíží toku zpráv. Glosář termínů GroupWise a ekvivalenty Exchange Server je poskytována na konci tohoto článku.

OBSAH

235362GroupWise Architecture (část 1): Domény a architektura poštovního

Úvod
GroupWise architektura domény
Hierarchie domény
Struktura adresáře a replikace
Struktura adresáře domény
Architektura groupWise poštovního
Struktura adresáře poštovního
Architektura úložiště zpráv

254346GroupWise Architecture (část 2): Řízení toku a glosář

254353GroupWise Architecture (část 3): Brána API

Další informace

GroupWise Message Flow

Jeden nejužitečnější dovednosti v GroupWise potíží je znalost jak GroupWise funguje toku zpráv. Následující oddíly a scénáře popisují tok zprávy natolik, že téměř všech else může být extrapolated.

Basic Message Flow Concepts

Architektura toku celé zprávy v GroupWise underlie několik základní koncepty:
  • Názvy adresářů jsou z hlediska agent přenosu zpráv (MTA), který byl původně nazývá "WordPerfect připojení serveru" (WPCS). Jako takové jsou všechny adresáře Wpcsin vstupní fronty MTA a všechny adresáře Wpcsout jsou fronty výstupu MTA.
  • Priorita fronty adresářů jsou téměř všechny stejné, s rozdíly v první dva adresáře:
    Wpcsin (or Wpcsout\<some agent>)
        \0              Time sensitive messages (for example, busy searches)
        \1              Administrative messages (for example, agent restart requests)
        \2              High priority messages
        \3              High priority statuses
        \4              Normal priority messages
        \5              Normal priority statuses
        \6              Low priority messages
        \7              Low priority statuses
    z důvodu tohoto faktu šarže může být znám o zprávě jednoduše zaznamenání jeho umístění: Postoff\Wpcsout\Ofs\5\3e528411.a19 je stav normální prioritou, který je čekajících na zpracování podle Agent poštovního (POA). Svou přítomnost implikuje, které:
    • Normální prioritou zpráva byla odeslána uživatelem na tomto poštovním a toto je stav vrácením aktualizovat původní zprávy. - a -

    • POA má není dosud zpracována tento stav. Stav lingers dostatečně dlouho v tomto adresáři, může předpokládá, že buď POA nepracuje správně nebo, je zpráva poškozený nějakým způsobem.

Delivery to a Local Recipient

V tomto scénáři Uživatel_a PostOffice1 odešle zprávu s přílohou Uživateli_b a UserC na stejné poštovního. Tento scénář předpokládá připojení TCP/IP (klient server), přestože (přímé) připojení UNC nebo mapovaný je prakticky stejné.
  1. Uživatel_a odešle zprávu. Klient GroupWise uživatele Uživatel_a přenáší zprávy POA pro PostOffice1.
  2. POA zapíše soubor přílohy Postoff\Offiles\Fd01d\83fe2651.01d.
  3. POA zapíše text zprávy a informace záhlaví zprávy zpráva záznam v Postoff\Ofmsg\Msg15.db (což je databáze uživatele Uživatel_a přiřazené zprávu) a zapíše ukazatel souboru přílohy v adresáři Offiles.
  4. Ukazatel POA zapíše do zprávy ve složce Odeslaná pošta uživatele Uživatel_a uživatele databáze (Postoff\Ofuser\User3vr.db).
  5. POA zapíše do zprávy ve složce Doručená zpráva databází Uživateli_b 's a jeho UserC ukazatel (Postoff\Ofuser\User87g.db a User2dd.db respektive).
  6. POA aktualizuje záznam zpráva se stavem "Dodáno".
  7. Pokud Uživateli_b a UserC jsou online, budou POA upozorní podle komunikaci s jejich GroupWise klientský software.
  8. Uživateli_b vidí oznámení, otevře zprávu a přečte ji. Tento fakt POA, které aktualizuje záznam zpráva se stavem "Otevřeno" pro Uživateli_b komunikuje Uživateli_b 's klientský software.
  9. UserC odstraní zprávy bez jeho čtení. Tento fakt POA, které aktualizuje záznam zpráva se stavem "Odstraněná" pro UserC komunikuje klientský software's UserC.
  10. Uživatel_a můžete otevřít vlastnosti zprávy ve složce a v tématu zpráva byla úspěšně doručena i uživatelům a dané Uživateli_b číst zprávy, zatímco UserC odstranil zprávu bez čtení jej.

Delivery to a Different Post Office, Same Domain

V následující situaci odešle Uživatel_a PostOffice1 UserD PostOffice2 normální prioritou zprávy. Obě pobočky příspěvku jsou ve stejné doméně. Tento scénář předpokládá, že MTA a POA nakonfigurovány pro vzájemnou komunikaci prostřednictvím služby TCP/IP, přestože komunikace prostřednictvím služby UNC je velmi podobný far jako týká přesunu prostřednictvím adresáře.
  1. Uživatel_a odešle zprávu UserD. Klient GroupWise uživatele Uživatel_a přenáší zprávy POA pro PostOffice1.
  2. POA PostOffice1 zapíše všechny přílohy adresářů Offiles zapíše záznam zprávu v Msg15.db (což je databáze přiřazené zprávy uživatele Uživatel_a) aktualizuje záznam zprávu s ukazatelem přílohy v adresářích Offiles a zapíše ukazatel na zprávu v databázi uživatelů uživatele Uživatel_a (User3vr.db)
  3. POA PostOffice1 zapíše celou zprávu ve formuláři přenos šifrované zprávy Postoff\Wpcsin\4.
  4. POA přenáší zprávy MTA pro doménu. Po MTA plně obdržel zprávu, POA zprávu odstraní z adresáře Wpcsin\4.
  5. MTA domény přijme zprávu a zapíše do adresáře Wpdomain\Mslocal\Gwinprog\4, zatímco komunikuje s POA PostOffice2.
  6. MTA domény komunikuje s POA PostOffice2 a přenáší zprávy. Při POA PostOffice2 úspěšně obdržel zprávu, MTA odstraní zprávy z Gwinprog\4.
  7. POA PostOffice2 provádí místní doručení stejný jako popsané v části "Doručování do místní příjemce". (Pokud MTA POA komunikace je nakonfigurován pro odkazy UNC, MTA zapíše zprávy do adresáře Postoff\Wpcsout\Ofs\4 PostOffice2 POA vyskladnění a potom provede místní doručení.)
  8. POA PostOffice2 generuje "Dodáno" stav pro zprávu a potom jej přenese MTA.
  9. MTA zapíše stav Wpdomain\Mslocal\Gwinprog\5, zatímco MTA komunikuje s POA na PostOffice1.
  10. POA na PostOffice1 obdrží stav z MTA a aktualizuje původní zpráva záznam se stavem "Dodáno" pro UserD.

Delivery to a Post Office in a Different Domain

Uživatel_a PostOffice1 Doména1 v tomto scénáři odešle zprávu s vysokou prioritou UserF PostOffice3 Domain2. Tento scénář předpokládá, že propojení mezi doménami je nakonfigurován přímého propojení TCP/IP.
  1. Uživatel_a odešle zprávu. Klient GroupWise uživatele Uživatel_a přenáší zprávy POA na PostOffice1, kde POA provádí počáteční kroky místní doručení popsaným v části "Doručování do místní příjemce" kroky 2 až 4.
  2. POA PostOffice1 zapíše soubor přenos šifrované zprávy jeho místní adresář Postoff\Wpcsin\2 ("2" protože toto je zpráva s vysokou prioritou) a komunikuje s MTA pro Doména1.
  3. MTA Doména1 přijme zprávu a zápisů do adresáře Wpdomain\Mslocal\Gwinprog\2. Po úspěšně MTA obdrží zprávu, POA PostOffice1 odstraní zprávy z adresáře Postoff\Wpcsin\2 na PostOffice1.
  4. MTA Doména1 komunikuje s MTA Domain2 a přenáší zprávy. MTA Domain2 zapisuje zprávu jeho místní adresář Wpdomain\Mslocal\Gwinprog\2. Po přenesení zprávu úspěšně MTA Doména1 odstraní zprávy z jeho místní adresář Gwinprog\2.
  5. MTA v Domain2 komunikuje s POA PostOffice3 a přenáší zprávy. Po zpráva úspěšně doručena, MTA Domain2 odstraní zprávy z jeho místní adresář Gwinprog\2.
  6. POA PostOffice3 provádí doručení místních zpráv popsané v části "Doručování do místní příjemce" kroky 2 až 5 a vygeneruje "Dodáno" stav.
  7. Stav "Dodáno" přenesen do MTA pro Domain2, které dočasně fronty zprávu jeho místní adresář Wpdomain\Mslocal\Gwinprog\3 ("3" protože je stav Vysoká priorita).
  8. MTA Domain2 přenáší stav MTA pro Doména1, který doručuje POA pro PostOffice1, které aktualizuje původní zpráva záznam se stavem "Dodáno" pro UserF.

Troubleshooting GroupWise Message Flow

Protože GroupWise zapíše disk na každé směrování souboru přenosu zpráv, můžete podle zastavení a spuštění jednotlivých agentů podél způsob a ověření, které zprávy je doručována kde byste izolovat problém přenosu zprávy. Protože GroupWise protokolování není vždy self-revealing, toto je někdy pouze metody pro řešení potíží toku zpráv.

Například pokud zprávu s vysokou prioritou uživatele Uživatel_a UserF (popsané v části "Doručování do poštovního v jiné doméně") není doručena, řešení tohoto problému můžete:
  1. Pro všechny agenty podél způsob protokolech. "Podrobné" protokolování je užitečný zejména úroveň protokolování při řešení problémů toku GroupWise zpráva protože příliš málo informace vede "Normální" protokolování a protokolování "Diagnostiky" vede příliš mnoho informací většina což je málo hodnoty.
  2. Zastavit MTA pro Doména1. Mít Uživatel_a zprávu odeslat. Ověřte, že nové zprávy bude zapsán do adresáře Postoff\Wpcsin\2 ("2" pro nejdůležitější zprávy) v PostOffice1. Pokud žádné nové zprávy je napsán existuje, může být problém s klientský software nebo POA PostOffice1. Pokud zde se zobrazí zpráva, pokračujte dalším krokem.
  3. Zastavit MTA Domain2 a spustit MTA Doména1. Ověřte, že se zpráva zobrazí v adresáři Wpdomain\Mslocal\Gwinprog\2 's Doména1, a že je zpráva odstraněna z adresáře PostOffice1 Postoff\Wpcsin\2. Soubor zpráv může být v adresáři Wpdomain\Mslocal\Mshold\Domxxxx\2 's Doména1, což je, kde jsou uloženy zprávy jsou zpožděny. Pokud ano, pokračujte dalším krokem. Pokud ne, problém může být s MTA Doména1.
  4. Zastavit POA PostOffice3 Domain2 a spustit MTA Domain2. Ověřte, že se zpráva zobrazí v Domain2 's Wpdomain\Mslocal\Gwinprog\2 adresáři nebo v adresáři Wpdomain\Mslocal\Mshold\Posxxxx\2.
A tak dále, dokud izolovat negligent agenta.

Další informace a řešení potíží více strategie naleznete online dokumentaci k Novell GroupWise na následujícím webu společnosti Novell:
http://www.novell.com/documentation/gw55/index.html?page=/documentation/gw55/gw55tsh1/data/a4ehiyt.html
Toto je konec část 2. Glosář termínů GroupWise následuje.

Část 3 Popisuje GroupWise API Gateway a nabízí podrobné návrhy při odstraňování potíží:
254353GroupWise Architecture (část 3): Brána API
Následuje kolekce GroupWise podmínky a jejich ekvivalenty Exchange Server.

Zmenšit tuto tabulkuRozšířit tuto tabulku
Termín groupWiseEkvivalent Exchange Server
UŽIVATELPříjemce (nebo poštovní schránky).
SkupinaDistribuční seznam.
Externí entitaVlastní příjemce.
ProstředekŽádný ekvivalent Exchange Server. Prostředek je poštovní schránky, která představuje místo (například konferenční místnosti) nebo prostředek (například zpětný projektor).
ADA (Administration Agent)Dsamain.exe (adresářové služby). Obvykle spouští pouze jednu instanci ADA pro celou doménu a všech poboček příspěvek v rámci domény.
MTA (Message Transfer Agent)MTA. Rozdíl je, obecně pouze jednu instanci GroupWise MTA služeb více poboček příspěvek v doméně, zatímco v Exchange Server, každý server (poštovního) spuštěna instance MTA Exchange Server.
POA (poštovního Agent)Store.exe (služba úložiště informací).
znovu vytvořenPodobný jediného počítače Exchange Server
DoménaPodobný Exchange Server webu, v, že je logické seskupení kanceláří příspěvek pro účely správy a směrování.
SystemPodobný organizaci Exchange Server, že je logické seskupení domén (weby) do souvislého název místa pro replikaci a zasílání zpráv účely.
Úložiště zprávPodobný v konceptu Exchange Server informace úložiště databází (Priv.edb a Pub.edb), ale v implementaci radically liší.
ZprávyEkvivalent zprávy v Exchange Server ale GroupWise zhruba díky srozumitelnější rozdílu mezi "pošty" zpráv, zpráv "schůzka" a "úkol" zpráv. Jiné typy zpráv zahrnout "Poznámky" a "telefonní" zprávy.
StavyZhruba ekvivalent dodání sestavy; však GroupWise má velmi formátovaným sadu stavů, že sestava zasílání zpráv událostí jako: doručeny, otevření, odpověděl, odstraněny, delegovány a vtáhnout. Stavy jsou také uloženy jako aktualizace existujících zpráv, nikoli jako samostatné zprávy.
Sdílené složky,diskusních skupin.
Poštovního databáze(Viz Directory úložiště).
Databáze domény(Viz Directory úložiště).
Úložiště adresářePodobné databáze adresářů Exchange Server (dir.edb), ale v implementaci radically liší. Úložiště adresáře domény názvem Wpdomain.edb a úložiště poštovního adresáře názvem Wphost.db.
DMS (Document Management System)Ekvivalentní, ačkoli Microsoft SharePoint Portal Server 2001 bude přímé ekvivalent, až bude k dispozici žádné Exchange Server.
Databáze guardianHrubý ekvivalentní informace ukládat protokoly transakcí v Exchange Server. Databáze Guardian (Ngwguard.db) zajišťuje integritu a spolehlivost informací v úložišti GroupWise zpráv.


Vlastnosti

ID článku: 254346 - Poslední aktualizace: 6. února 2014 - Revize: 3.5
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Klíčová slova: 
kbnosurvey kbarchive kbmt kbinfo KB254346 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:254346

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com