Atgūt kad Google Apps nav Uzņēmumu

Šis ir stāsts par IT, mākonis un visas lielas un šausminošas lietas, kas notiek, kad abas sanāk kopā. In many ways cloud computing and Software as a Service (Saas) Ir nepieciešams trūkst svētību, overworked Informācijas tehnoloģijas departamentu, kuri plāno sasniegt labākos tehnoloģijas var piedāvāt ar 100% uptime un bez budžeta. With the emergence of web enabled services from major vendors like Amazon, Microsoft, and Google the age old question posed to IT professionals — tas bez maksas - Beidzot būtu atbildēt ar pārsteidzošām jā! (Vismaz vienkāršākās versijas).

Bet, tāpat kā daudzi no mūsu vecvecāki teica pirms, pieredze mācīja, ka veco adage joprojām ir: jums, ko jūs maksājat. Protams, pakalpojumam, iespējams bez, bet bez pakalpojumu līmeņa nolīgumā (SLA) nav jāizmanto, ja ir e-pasts nobirums, piemēram, 6 mūsu vairāk zudumiem kas ietekmēja Google Mail 2009. But worry not end users! Ir maksā uzlabojumi pieejams, kas ietver, SLA, garantējot 99.9% uptime, kā arī tālruni un e-pasta atbalstu kritiskās problēmas. At $50 vienam lietotājam vienā gadā tas izklausās nozagt!

Kas tieši tā tie nozīmē, ko uptime un kritisko?

Tas viss izskatās lieliski uz papīra; nav nepieciešams, lai nodrošinātu fiziskas aparatūras aktīvu, nav IT darbiniekiem maksāt, un izmaksas ir mazāk nekā licenču vien lielākajai daļai standalone risinājumi! Diemžēl, šīs tirdzniecības garantijas izskatīsies vaporware, kad datus hits maršrutētāju.

Lai ilustrētu nepilnību mākonis, Let's izmantot reālās dzīves piemērs. Bezpeļņas klientu mēs saucam par “Labdarības X” vēlējās, lai samazinātu pieskaitāmās un uzlabotu pakalpojumus saviem darbiniekiem. Pēc vairāk nekā desmit gadu pārkraušanas e-pastu un pakalpojumi iekšēji, viņi nolēma tas bija laiks, lai pārietu uz mākonis. Fortunately for them, kā bezpeļņas institūcija tie kvalificējās bezpeļņas izdevums Google Apps. Liels!

Lūk pabalstiem, ko tās lūdz:

1. Mēs varam samazināt mūsu joslas platuma izmantošanu ne apstrādes e-pastu sevi
2. Mūsu serveris resursi tiek atbrīvots, un to var izmantot citiem mērķiem
3. Mēs varam nodrošināt labāku webmail, lai mūsu darbinieki.
4. Mēs piekļūt kopīgos resursus, piemēram, kontaktu pārvaldības un dokumentus, kas ir ‘kas mākonis‘

Patiesībā, lai gan bija, ka šīs izmaiņas nav tik vienkārši, kā tie bija gaidāms. Tā wasn'ta jautājums noklikšķiniet uz migrē lietotāji.

Tas ir, kad Labdarības X sauc mani.

Es sāku ar konfigurēšanu to Google Apps konta un iet caur procesu modernizācijas to bezpeļņas valodā. Es pārvietoti viņu lietotāja pastu, izmantojot celta migrācijas rīkus, and I synchronized the user accounts with Google Apps Directory Sync Tool (GADS). And that is where the utilities fell short. It appears that Google doma about the idea of users synchronizing their active directory passwords with Google Apps. I emphasize thought, jo acīmredzot tas ir, cik vien Google got. Want Single Sign On? Want Synchronized passwords using LDAP or AD? Laiks vērsties pie trešās puses rīkus. Labi, godīga pietiekami. Trešās puses līdzekļi ir pieejami, kā to izdarīt, un viņi strādā. Nekādu kaitējumu, nav pretrunā. Bet nedaudz vairāk dokumenti par šo jautājumu nebūtu cietis.

Tad visi ellē izputējis zaudēt. Lietotāju nedaudz nevarēja ielogoties savu Google kontu. Tātad par iemeslu medībām sāka.

Tās bija apturēta? - Nav!

Viņi bija, izmantojot nepareizu paroli - Nr!

Vai es varu atjaunināt savu paroli - Nr?

Strangely I could not update their user accounts using the web interface. Any change — password, iesaukas, e-pasta maršrutēšanu, nosaukumi - rezultātā nezināma kļūda #1000.

Labi, Es domāju,. Tā saka, mēģiniet vēlreiz vēlāk, but I should be able to update their password using GADS.

GADS FAIL — 1301 Uzņēmumam neeksistē!

The GADS logs indicated that the user does not exist. Tas bija negaidīts, jo es tikko paskatījos lietotāja informāciju tīmekļa saskarni, un tas pavisam noteikti bija eksistē.

Biļešu laiks

Laiks, kas atbalsta realizēta! Tā kā šis ir bezpeļņas valodā, atbalsts ir iekļauts. Tāpēc es noklikšķinājuši atbalstu un sekoja maršrutēšanas jautājumiem. Google konstatēts, ka tas nav "kritiskā’ jautājums, jo pakalpojums nav noteiktas pilnībā, un es nevaru teikt, es nepiekrita. Google teica, ka atbalsta tikai iespēja būtu pieejama, ir esupport.

Es aizpilda veidlapu, un tika ātri sagaidīs ar draudzīgu e-pastu no vienas no to klientu apkalpošanas pārstāvjiem,. The representative worked with me to quickly determine that this issue was beyond his level of expertise and escalated the ticket to a specialist.

Līdz šim tik labi.

Tad es gaidīju 3 dienas. Es saņēmu pieprasījumu, personāla par to, kad viņi varētu pārbaudīt savu e-pastu. Ja tas būtu noteikts? Viņi bija termiņi un svarīgi jautājumi, kurus nepieciešams risināt to iesūtnes.

Es jautāju atbalstu, kas atbildēja, ka viņi “nezinu workarounds brīdī.” Vienīgā iespēja, ka mums bija iespēja nākt klajā ar bija, lai izdzēstu kontu un atjaunot to – nav ļoti labs risinājums, jo visi pasta pazustu starp pāreju un laiku konta var tikt pārbūvēts.

Lai mēs gaidīja vēl daži. E-pasts pat nevarēja nosūtīt cietušo lietotājiem - jebkuras izmaiņas e-pasta maršrutēšanu izraisīja nezināma kļūda.

Pagājis nedēļas, tāpēc es ievietojis ar Google atbalsta forumā cerot, kāds - kāds - būtu ierosinājums par to, kā noteikt vai PROFILAKSE jautājumu. Lietotājam pēc lietotāja ziņoja līdzīgas problēmas, jo Google pārejas Apps lietotājiem Google kontiem, bet nebija rezolūcijas, kas nav jāgaida manuālas Google darbinieks.

Laiks turpina atzīmējot

Pēc astoņu dienu gaida es nonācu pie risinājuma, par savu.

Jo izrādījās, ka konti tika daļēji izveidoti (tās parādījās tīmekļa saskarni, un varētu saņemt e-pastu, bet nevar mainīt vai piekļuves pakalpojumiem) izrādījās, viņu bija kļūda, kā grāmatvedība, kuri pārstrādāti izveidi. It seemed clear to me that the problem was an inconsistency in Google’s infrastructure. Noņemot konti dotu sistēmas, lai vienotos par konta stāvokli, bet varētu abi būt vienoties, ka pārskati bija? 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, bet neskatoties uz auto-aizpildiet atzīstot to lietotājvārdu, kad es noklikšķinājuši nākamais man tika dota kļūdas, ka pārskati nepastāv.

Mans nākamais pieeja bija izveidot jaunu lietotāju ar tādu pašu nosaukumu, izmantojot panelī. Šajā laikā man bija teicis, ka bija kļūda, jo pārskatos nebija pastāv. Protams, ka bija divas atsevišķas sistēmas tiek apšaubīts.

Tas notika ar mani, ka es varētu būt iespēja, lai iegūtu vairāk noderīgu kļūdu ziņojumus, dodoties uz komandrindas. Tāpēc es uzstādītas Google Apps Manager, kas ir arī pazīstams kā GAM. GAM izmanto Google Apps uzkrājumu API, kas mijiedarbojas ar Google Apps kontu.

I ilga vairākus jautājumiem par kontu es zināju, ka tas ietekmē, izmantojot GAM, lai redzētu, kas noticis. While queries would return data about the username, iesaukas, un vai tie bija vienojušies ar pakalpojuma noteikumiem, lietotāji nevar mainīt, atpakaļ kļūda “1301 uzņēmumam neeksistē”. Tāpēc es centos radīt lietotājam atkārtoti, kas bija negaidīti rezultāti.

ServerBusy(1001)

Savādi, Man bija teicis, ka sistēma ir aizņemta. Tāpēc es gaidīju un mēģināju vēlreiz.

EntityExists(1300)

Kā es aizdomas, tā man teica konts jau pastāv. Bet no zinātkāre, Es centos login.

Tas strādāja

Kaut kāda iemesla dēļ, Es tagad var pieteikties uz attiecīgajiem kontu. Es mēģināju citu kontu.

ServerBusy(1001)

Domāju varbūt šī kļūda nozīmēja vairāk nekā tas bija izīrēšana gada, I mēģināja pieteikties uz šo otro kontu, pirms mēģināt vēlreiz. Šis konts tagad arī strādā, kā paredzēts.

I pārbauda paneli un web interfeiss tagad strādāja, kā paredzēts šajos kontos, kā arī.

Lai gan atbilde bija dīvaini, neatkarīgi noticis uz servera gala parādījās, lai novērstu šo problēmu,, tāpēc es bija skripts, kas satur visus ieinteresētos lietotājus un atrisināt problēmas, par atlikušo kontu.

Mākonis vajadzībām amortizatori

Charity X is now working merrily away using Google Apps, Docs, un citus instrumentus, kas mākonis, bet pārejas posms, ir skaidri norādījusi, apsaimniekošanu, ka tur isn'ta burvju krāsns, ka jūs varat “noteikt un aizmirst” kad runa ir par IT. Kamēr vēl ir liela vērtība, un ietaupīt bija mākonis, Šajā dīkstāves ir disconcerting kā IT administrators. When I run my own systems, Es zinu, kas notiek aiz ainas, un ja kaut kas noiet greizi es zinu, kur meklēt atbildes. With hosted services I am at the mercy of third parties to provide adequate documentation and timely support. Pat ja mans darbs ir ne problēmas cēloni, Es joprojām sniegs risinājumus saviem klientiem ātri. Kad es nevaru skatīties ar kapuci, Man vajag partneri, kas var atrisināt problēmas stundu laikā - ne nedēļas. Klientu atbalsta līdzekļiem, kas nodrošina faktiskā risinājumi. Vienkārši atzīstot problēmu nepietiek.

Ja mākonis pakalpojumu sniedzēji ir vying par piekļuvi ienesīgs līgumus ar valsts un federālās aģentūras un lielās korporācijas ir svarīgi, lai viņi atceras, ka katra klienta skaita. Tad, kad lietotājs nevar piekļūt savu e-pasta var nebūt uzskata par izšķiroši svarīgu Microsoft vai Google, bet tas ir svarīgs jautājums, lai šis lietotājs. A week of downtime is simply unacceptable to users, īpaši, ja skartais lietotājs notiek, ir lēmumu pieņēmējs.

Es ceru uz mākonis pakalpojumu, kas darbojas kā burvju krāsnī, but for the foreseeable future I see only job security in mākonis.