E munka kapcsán arra gondoltam, hogy a Joomfish-hez elkészítem a nyelvi fájlt is. Nos az alap csomaghoz már volt aki megcsinálta, így most azt – egyenlőre változatlan formában – közre adom, ha valaki még nem ismerné. Természetesen erre alapozva a most fejlesztett megoldást is kiegészítem.

http://www.althea.ro/en/download/6-extensions-for-joomla-1-5.html

Szép kihívás! Nézegettem és megpróbáltam logikusan gondolkodva eredményre jutni. Sok minden látszik – és a programozói múlttal érthető is – de végül teljes sikert nem tudtam elérni. A kisérletek alapján nekizuhantam a netnek és az alábbi linken egy jó és hasznos megoldást sikerült találnom:

http://exchangeserverpro.com/how-to-move-wsus-30-to-a-new-server

A cikk tiszta és világos, s így együtt már sokmindenre választ és megoldást adott. Remélem sokaknak segít még.

Egy darabig nem ez volt a legfontosabb, de hát az ember szépre akarja reszelni a rendszerét, így ezt is kikerestem, megoldottam. A problémát az okozta, hogy a szerver nem tudja merre menjen kicsiny AD rendszerünkben és lassabban találja meg az infót, mint az EMC amennyit várni hajlandó.

Az aktuális beállításokra a Get-ADServerSettings kapcsoló által adott infók segítenek megjelennie.

[PS] C:\Windows\system32>Get-ADServerSettings | fl

RunspaceId                                 : 24e38aa9-d719-4708-b2e8-a423fb615dfb
DefaultGlobalCatalog                       : SERVER01.company.org
PreferredDomainControllerForDomain         : {}
DefaultConfigurationDomainController       : SERVER01.company.org
DefaultPreferredDomainControllers          : {SERVER01.company.org}
UserPreferredGlobalCatalog                 :
UserPreferredConfigurationDomainController :
UserPreferredDomainControllers             : {}
RecipientViewRoot                          : company.org
ViewEntireForest                           : False
Identity                                   :
IsValid                                    : True

A fentiekben a “hiányok” már érzékelhetőek is, azaz vár ránk a Set-ADServerSettings kapcsoló, amivel beállíthatjuk a számunkra szükséges értékeket.

NAME
    Set-AdServerSettings

SYNOPSIS
    Use the Set-AdServerSettings cmdlet to manage the Active Directory Domain Services
    (AD DS) environment in the current Exchange Management Shell session. The
    Set-AdServerSettings cmdlet replaces the AdminSessionADSettings session
    variable that was used in Microsoft Exchange Server 2007.

SYNTAX
  Set-AdServerSettings [-ConfigurationDomainController <Fqdn>] [-Confirm  
    [<SwitchParameter>]] [-PreferredGlobalCatalog <Fqdn>] [-RecipientViewRoot
    <String>] [-SetPreferredDomainControllers <MultiValuedProperty>]
    [-ViewEntireForest <$true | $false>] [-WhatIf [<SwitchParameter>]]
    [<CommonParameters>]

  Set-AdServerSettings -PreferredServer <Fqdn>
    [-Confirm [<SwitchParameter>]] [-RecipientViewRoot <String>]
    [-ViewEntireForest <$true | $false>] [-WhatIf [<SwitchParameter>]]
    [<CommonParameters>]

  Set-AdServerSettings –RunspaceServerSettings  
    <RunspaceServerSettingsPresentationObject> [-Confirm [<SwitchParameter>]]
    [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Amennyiben a fenti paramétersorral a dolgokat megfelelően beállítjuk, akkor a probléma megszűnik.

Get-Mailbox -Arbitration -Database db1 | New-MoveRequest -TargetDatabase db2

Ezt követően a dolog már minden gond nélkül a megszokott eljárásokkal lefolytatható volt.

powercfg.exe /hibernate off

Részletesebben: http://support.microsoft.com/kb/920730

   Ugrás a méretező excel tábla lelőhelyére

Véleményem szerint ezeket a méretezéseket el lehet fogadni mint kiinduló alap, s ha valaki olyan méretű rendszert csinál mint az MS-es kollégák akkor kell is, de azért lehetséges ésszel figyelembe venni a kapott eredményeket. Viszont ezek mint korrekt kiindulási alap elfogadhatóak, és ezek változtatása mindenkinek a saját businesse már.

A legegyszerűbb megoldás az Exchange 2010 konzolon a Move Request lehetőségek kihasználása, melyekből kétféle adódik jelenleg (Exchange 2010) számunkra:

• Local Move – Exchange Organizáción belüli mozgatás
• Remote Move – Eltérő erdőre való mozgatás

A fentiek alapján azt hiszem itthon inkább az első lesz a mindennapi :) változat.

Exchange Administrator

Az Exchange Administratorban jelöljük ki a számunkra lényeges postaládákat és a jobb egérgomb megnyomására megjelenő menüben válasszuk ki a szükséges mozgatás típust – pl. New Local Move Request.

A megjelenő varázslót értelem szerűen kattintsuk végig – annyira egyértelmű, hogy nem érdemes leírni és kifotózni – majd az egész végeredményeképpen a rendszer valamennyi feladatot a Move Request gyűjtőbe zsúfolja be és a továbbiakban itt követhetjük nyomon a dolgok alakulását.

Exchange Management Shell

Bár a fenti megoldás igencsak kényelmes, de vannak helyzetek ahol kimondottan előnyös, ha scriptből tudjuk elvégezni a dolgokat. A mozgatáshoz a következő két parancs lehet számunkra fontos:

• Mozgatás elindítása
  New-MoveRequest –Identity username –TargetDatabase “database name”
• Mozgatás állapota
  Get-MoveRequest [–Identity username]

http://isaserver.spaces.live.com/blog/cns!985DD920BD947A38!720.entry 

Potenciális Excange 2010 hibaforrásra szeretném felhívni a figyelmet:

• A PF storet nem tudod DAG-hoz rendelni
• OAB generálásra csak a Mailbox Role gépek képesek
• Ha minden Mailbox Role géped DAG tag, akkor hova teszed a PF adatbázist? 
  Válasz: teheted bármelyik gépre, de a DAG-hoz nem adhatod hozzá az adatbázist, ez eddig rendben is van
• Viszont ahhoz, hogy a PF-be tudja publikálni az OABGen Server az OAB-ot, legalább egy mount-olt Private IS kell
  Tehát, ha egy “passzív” DAG tagon van a PF, ahol nincs mountolt Private store, akkor nem fog menni az OAB Generálás

Többit lásd a fent hivatkozott cikkben.

Error:
Active Directory operation failed on <<DOMAIN CONTROLLER NAME>>. This error is not retriable. Additional information: The name reference is invalid.
This may be caused by replication latency between Active Directory domain controllers.
Active directory response: 000020B5: AtrErr: DSID-03152392, #1:
0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200f4 (homeMDB)

A value in the request is invalid.

Exchange Management Shell command attempted:
new-mailboxdatabase -Server ‘<<MAIL SERVER NAME>>’ -Name ‘Administration’ -EdbFilePath ‘E:\Administration\Administration.edb’ -LogFolderPath ‘E:\Administration’

Elapsed Time: 00:00:00

Mount Administration
Cancelled

Elsőre néztem, mint a moziban, hisz nem nagyon láttam mi is lehet a gond. Ezt követően nézmi túrás a neten és arra jutottam, hogy a szerverem nem tudja mely szerverek szolgálják, szolgálhatják ki.

Get-ADServerSettinngs | fl

Ennek beállítását ezután már egyszerű volt megoldani, csak egy egyszerű Power Shell parancs és megy is minden:

Set-ADServerSettings –PreferredServer [insert DC FQDN here]

A beállítást követően még egyszer ellenőriztem, hogy sikeres voltam-e, majd irány a MailBox DB létrehozása – és igen, így már minden megy rendesen.

Nem akarom a terméket most részletesen bemutatni, hisz ez véleményem szerint a vonatkozó weboldalak dolga. Javaslom viszont, hogy akinek van rá módja töltse le a próba változatot és mazsolázza végig.

szólj hozzá: 2030 második rész

Hosszas magyarázkodás helyett álljon itten a megoldás, törölni kell a registry-ből a  HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate kulcsot (a teljes kulcsot és ami alatta van), majd újra kell indítani a Windows Update Service-t.

Akit részletesebben érdekel az nézze meg a vonatkozó blog bejegyzést.

Az így elkészült anyagot a nyilt forráskód szellemében én is szabaddá teszem, a letölthető anyagokkal, leírásokkal egyetemben.

További információkért lásd a termékhez készült leíró oldalt: www.atlantico.hu/joomla/simplecaddy

Mindez persze nem változtat a tényen, hogy 176 millió Gmail felhasználót megkérdezés nélkül vontak be a Buzzba. A Google, akármennyire sajnálkoznak is most, nem sokat törődik a magánélet szentségével – Eric Schmidt tavaly év végén úgy nyilatkozott, "csak a gazembereket érdekli a netes titoktartás", azaz úgy veszik, ha az embernek nincs rejtegetni valója, akkor nyugodtan a világ – illetve ismerősei – elé tárhatják tevékenységét. A The Register szerint a "nagy terv" része volt, hogy nem tesztelték előbb a Buzzt egy kisebb csoporton, inkább egy hirtelen lépéssel kész helyzet elé állították a felhasználókat, hiszen utólag is bőven van lehetőség a módosításra.

Index.hu

Ami érdekes ebben, az a hozzáállás:

• Nem zavarj a Google-t, hogy a felhasználókat (176 millió ember) kérdés nélkül ennyire meztelenné teszi. Jó szöveg ugyan a “ha nincs titkolni valód, akkor minek nyafogsz”, de ez csak melléduma. Érdekelne, hogy ha Eric Schmidt úr minden levelét és dokumentumát mindenki olvashatná, kapcsolatait böngészhetné mit szólna hozzá? Lehet hogy Ő azért meri ezt kijelenteni, mert nem mindenkit vállal fel akit ismer?
• A másik gondom, hogy a Google-t eddig sem tartottam egy megbízható szoftvereket gyártó cégnek, ráadásul egyre nagyobb és nagyobb terveik vannak, láthatóan és egyre többször bizonyítottan tesztelések, kitesztelés nélkül.

Azt nem értem, miért teheti ezt meg egy ilyen méretű cég? Mi ennek tizedéért örökre lehúzhatnánk a nemzetközi vizeken a rolót (a helyi hozzáértőket most tudatosan nem nézem, mert azok mindenhol vannak).

Szóval olvasom és nem értem…

http://support.microsoft.com/kb/938245/