Gendannelse da Google Apps vinder Enterprise

Dette er en historie om IT, skyen og alle de store og forfærdelige ting, der sker, når de to mødes. In many ways cloud computing and Software as a Service (SaaS) er en velsignelse for underbemandet, overanstrengt Informationsteknologi afdelinger, som forventes at levere den bedste teknologi har at tilbyde med 100% oppetid og noget budget. With the emergence of web enabled services from major vendors like Amazon, Microsoft, and Google the age old question posed to IT professionals — er det gratis - Endelig kan besvares med et rungende ja! (I det mindste for basisversionen).

Men ligesom mange af vores bedsteforældre har sagt før, erfaringen har lært, at det gamle ordsprog er stadig: du får hvad du betaler for. Sikker, tjenesten kan være gratis, men ingen service level agreement (SLA) Der er ingen brug, når der er en e-mail udfald som 6 vores mere udfald , der ramte Gmail i 2009. But worry not end users! Der er betalt opgraderinger tilgængelige, indeholde en SLA garanterer 99.9% oppetid samt telefon og e-mail support til kritiske spørgsmål. At $50 per bruger per år, det lyder som en stjæle!

Hvad præcis gør de forstår ved uptime og kritisk?

Det hele ser godt ud på papiret; Der er ingen grund til at opretholde fysisk hardware aktiver, ingen it-medarbejdere til at betale, og omkostningerne er mindre end licenser alene for de fleste standalone løsninger! Desværre, Disse markedsføring garantier ligner vaporware når data hits routeren.

For at illustrere manglerne i skyen, lad os bruge en virkelige liv eksempel. En ikke for profit kunde, vi vil kalde “Velgørenhed X” ønskede at reducere overhead og forbedre servicen for deres personale. Efter mere end et årti til at håndtere e-mails og tjenester internt, De besluttede at det var tid til at flytte til skyen. Fortunately for them, som en ikke for profit institution de kvalificeret sig til non-profit-udgave af Google Apps. Stor!

Her er de fordele, de søgte:

  1. Vi kan reducere vores brug af båndbredde ved ikke håndtering e-mail os
  2. Vores server ressourcer vil blive frigjort og kan anvendes til andre formål
  3. Vi kan give bedre webmail for vores medarbejdere.
  4. Vi får adgang til delte ressourcer såsom kontakt ledelse og dokumenter, der er ‘i skyen

Virkeligheden selv var, at denne ændring ikke var så enkelt, som de havde forventet. Det var ikke spørgsmålet om Klik migrere brugere.

Det er når Charity X kaldte mig.

Jeg begyndte med at konfigurere deres Google Apps-konto og går gennem processen med at opgradere den til non-profit-udgave. Jeg migreret deres brugerens mail ved hjælp af den indbyggede overflytningsværktøjer, and I synchronized the user accounts with Google Apps Directory Sync Tool (ÅR). And that is where the utilities fell short. It appears that Google tænkte about the idea of users synchronizing their active directory passwords with Google Apps. I emphasize thought, fordi der tilsyneladende, der er så langt som Google fik. Want Single Sign On? Want Synchronized passwords using LDAP or AD? Tid til at henvende sig til udenforstående værktøj. Okay, fair nok. Tredjeparts værktøjer er tilgængelige til at gøre dette, og de arbejder. Ingen skade, ingen fejl. Men en lidt mere dokumentation om emnet ville ikke såre.

Så alle helvede brød løs. En håndfuld af brugere kan ikke logge ind på deres Google-konti. Så jagten på årsagen begyndte.

Var de suspenderede? - Ingen!

Var de bruger forkert password - nr.!

Kunne jeg opdatere deres password - nr.?

Strangely I could not update their user accounts using the web interface. Any change — password, øgenavne, e-mail routing, navne - resulterede i en ukendt fejl #1000.

Okay, Jeg tænkte. Det siger at prøve igen senere, men jeg shoulda kunne opdatere theire Brug adgangskode ÅR.

ÅRET FAIL - 1301 Enhed eksisterer ikke!

Året, at vinduet oplyste bruger findes ikke. Det var uventet, da jeg lige havde kigget på brugerens oplysninger i webgrænsefladen, og det helt sikkert fandtes.

Billet Time

Tid til at støtte at sparke i! Da dette var en non-profit-udgave, support er inkluderet. Så jeg klikkede støtte og fulgte routing spørgsmål. Google fastslået, at dette ikke var en »kritisk’ karakter, da den service blev ikke helt ned, og jeg kan ikke sige, at jeg var uenig. Google sagde den eneste støtte valgmulighed er eSupport.

Jeg udfyldte skemaet, og blev hurtigt mødt med en venlig e-mail fra en af ​​deres kundeservice repræsentanter. The representative worked with me to quickly determine that this issue was beyond his level of expertise and escalated the ticket to a specialist.

Så langt så godt.

Jeg så ventede 3 dag. Jeg har modtaget henvendelser fra personalet om, hvornår de kunne tjekke deres e-mail. Hvornår vil det blive fastsat? De havde deadlines og vigtige spørgsmål, der skulle behandles i deres indbakker.

Jeg spurgte støtte, som svarede, at de “kender ikke nogen løsningerne i øjeblikket.” Den eneste mulighed, at vi var i stand til at komme op med, var at slette kontoen og oprette den igen – ikke en meget god løsning, da alle e-mails vil gå tabt mellem overgangen og den tid den konto kunne genskabes.

Så vi ventede lidt mere. Den e-mail kunne ikke engang blive fremsendt til de berørte brugere - alle ændringer til e-mail routing resulterede i en ukendt fejl.

En bestået uge, så jeg indsendt til Googles support-forum håber nogen - nogen - ville have et forslag om, hvordan du løser eller løsning på problemet. Bruger efter bruger rapporterede lignende problemer, da Google's overgang Apps-brugere til Google Konti, men der var ingen andre opløsninger end at vente på manuel indgriben fra en Google-medarbejder.

Tid bliver ved med tikkende

Efter otte dages venten kom jeg til en løsning på min egen.

Da det viste sig, at regnskaberne var delvist skabt (De dukkede op i web-interface og kan modtage e-mail, men kunne ikke ændres eller adgang til tjenester) Det fremgik af deres havde været en fejl i, hvordan regnskaberne blev behandlet under oprettelsen. It seemed clear to me that the problem was an inconsistency in Google’s infrastructure. Fjernelse af konti vil give de systemer til enighed om den konto status, men kunne de begge blive enige om, at regnskabet forelå? Perhaps I could force Google to recreate the already existing accounts without losing the current data.

I attempted to rerun the transition to Google Accounts on the affected users manually, men på trods af auto-fill anerkende deres brugernavne, når jeg har klikket næste jeg fik en fejl, at regnskabet ikke eksisterede.

Min næste fremgangsmåde var at oprette nye brugere med de samme navne med instrumentbrættet. Denne gang fik jeg at vide at der var en fejl, fordi regnskabet forelå. Klart, at der var to separate systemer, der forespørges.

Det forekom mig, at jeg måske kunne få mere brugbare fejlmeddelelser ved at gå til kommando-linje. Så jeg installerede Google Apps Manager, som også er kendt som GAM. GAM bruger Google Apps-API til at interagere med Google Apps-konto.

Jeg løb en række forespørgsler på konti jeg vidste var berørt bruger GAM til at se, hvad der skete. While queries would return data about the username, øgenavne, og om de havde aftalt at vilkårene for tjenesten, brugerne kunne ikke ændres, returnere fejl “1301 enhed eksisterer ikke”. Så jeg prøvede at oprette bruger igen, som havde en uventet resultat.

ServerBusy(1001)

Mærkeligt, Jeg fik at vide, at systemet var optaget. Så jeg ventede og prøvede igen.

EntityExists(1300)

Som jeg mistænkte, det fortalte mig, at kontoen allerede fandtes. Men ud af nysgerrighed, Jeg forsøgte at logge ind.

Den virkede

Uanset af hvilken grund, Jeg var nu i stand til at logge på den berørte konto. Jeg prøvede en anden konto.

ServerBusy(1001)

Tænker måske denne fejl betød mere, end det var at lade den, Jeg forsøgte at logge ind på denne anden konto, før du prøver igen. Denne konto nu også fungeret som forventet.

Jeg tjekkede instrumentbrættet og web-interface nu fungeret som forventet på disse konti samt.

Mens svaret var mærkeligt, Uanset hvad der skete på serveren ende syntes at løse dette problem, så jeg kørte et script, der indeholdt alle berørte brugere og løst problemerne på de resterende konti.

Skyen behov støddæmpere

Charity X is now working merrily away using Google Apps, Docs, og andre værktøjer i skyen, men overgangen har gjort det klart for ledelsen, at der ikke en magisk ovn, kan du bare “sæt og glemme” når det kommer til it. Mens der stadig er en stor værdi og besparelser at hente i skyen, denne nedetid er foruroligende som en it-administrator. When I run my own systems, Jeg ved, hvad der sker bag kulisserne, og hvis noget går galt ved jeg hvor man skal lede efter svarene. With hosted services I am at the mercy of third parties to provide adequate documentation and timely support. Selv om mit arbejde er ikke årsagen til problemet, Jeg er stadig forventes at levere løsninger til mine kunder hurtigt. Når jeg kan ikke se under kølerhjelmen, Jeg har brug for partnere, der kan løse problemerne i timer - ikke uger. Kundesupport, betyder at give konkrete løsninger. Du skal blot anerkender et problem er ikke nok.

Når skyen udbydere kappes for at få adgang til lukrative kontrakter med statslige og føderale agenturer og store virksomheder er det vigtigt, at de huske, at hver kunde tæller. Når en bruger ikke kan få adgang til deres e-mail er det måske ikke anses for kritisk til Microsoft eller Google, men det er et kritisk spørgsmål til den pågældende bruger. A week of downtime is simply unacceptable to users, især hvis den pågældende bruger tilfældigvis en beslutningstager.

Jeg ser frem til cloud-tjenester, der fungerer som en magisk ovn, but for the foreseeable future I see only job security in skyen.