SharePoint – Open in Windows Explorer

Viena no vislabākajām SharePoint funkcijām ir iespēja atvērt folderus ar Windows Explorer un tālāk jau darboties kā ar jebkuru citu direktoriju*. Diemžēl, staigājot apkārt ar savu portatīvo datoru un pamīšus izmanotjot VPN, man pārlieku bieži uz ekrāna atvērās nevis gaidāmais logs, bet gan paziņojums “Your client does not support opening this list with Windows Explorer.” Maigi izsakoties, kaitinoši, jo tas parādījās un pazuda bez redzama iemesla (reizēm, spiežot jau piekto reizi, pēkšņi nostrādā).

Liekas, ka izdevās atrast nosacītu risinājumu šai problēmai – ver vaļā Local Services un restartē WebClient servisu.

* Folderis nav tā pati direktorija… Direktorija ir fiziska mape uz cietā diska. Folderis ir jebkas, ko operētājsistēma var atvērt kā mapi, piemēram, šī SharePoint mape vai Library mape uz Windows 7.

MSSQL rezerves kopiju veidošana

Lai risinātu iepriekš aprakstītās problēmas, veidojot MSSQL automātiskās rezerves kopijas, izveidoju savu mazu programmiņu. Tās galvenās funkcijas:

  • veidot rezerves kopijas visām uz servera esošām datubāzēm;
  • apstrādāt reizē vairākus datubāzu serverus (vai instances);
  • sūtīt skaisti noformētus statusu pārskatus;
  • izdzēst novecojušas rezerves kopijas.

Lejupielāde: SqlBackup.zip (gan pirmkods, gan kompilēta versija)

Konfigurācijas fails un pirmkods ir dokumentēts pietiekoši, lai jebkurš šo kodu varētu izmantot, pielāgojot vai arī neko nemainot.

MSSQL rezerves kopiju problēmas

Savulaik, strādājot ar MySQL, priecājos par iespēju veidot ērtas rezerves kopijas ar mysqldump. Pēcāk, pārejot uz Microsoft SQL Server, priecājos par iespēju izmantot iebūvēto rezerves kopiju veidošanu, kas gan nebija tik ērti izmantojama citiem mērķiem kā parasti SQL skripti, bet toties tika veidoti krietni ātrāk un deva iespēju veidot inkrementālas rezerves kopijas.

Tomēr pēc kāda laika tika apzinātas vairākas problēmas, kas piemīt iebūvētajām backup funkcijām, kad tās izmanto, piemēram, katras nakts rezerves kopiju veidošanai, no kurām dažas:

  • nav iespējams norādīt, pret kuru pilno rezerves kopiju tiks veikta inkrementālā – tā vienmēr būs pret pēdējo pilno;
  • nav iespējas automātiski dzēst vecās rezerves kopijas (lai gan katrai rezerves kopijai var norādīt, cik ilgi tā būs derīga).

Otro problēmu daļēji risina Maintenance plan uzdevums, kas tīra rezerves kopiju vēsturi. Taču – tas tīra rezerves kopijas, nevis, ievērojot katras kopijas derīguma laiku, bet gan visas, kas vecākas par x dienām.

Pirmo problēmu iespējams daļēji risināt, izmantojot COPY_ONLY parametru BACKUP operācijai. Tas gan neļauj norādīt, ka inkrementālā kopija jāveido uz noteiktas pilnās kopijas bāzes, taču tas ļauj izveidot kopijas, kas ir neatkarīgas, un kuru izdzēšana nesabojās kādu citu kopiju.

Tieši šis pēdējais faktors bieži ir bijis ļoti svarīgs – ir nepieciešams izveidot automātiskās rezerves kopijas katru nakti, bet paralēli tam nepieciešams ļaut datubāzes administratoram pašam spēlēties ar savām rezerves kopijām – tās dzēst, veidot utt. Un automātiskās kopijas netiek glabātas ilgāk kā, piemēram, nedēļu, kamēr manuāli veidotās var tikt saglabātas bezgalīgi.

Lai ar šīm problēmām cīnītos, kā arī ērti automatizētu vairāku servera instanču rezerves kopiju veidošanu, uzrakstīju nelielu programmiņu, kas automātiski veic šādu kopiju veidošanu. Programmu ar visu pirmkodu drīzumā nopublicēšu, ja nu gadījumā vēl kāds atpazīst aprakstītajā savas problēmas (vai varbūt tagad saprot, ka savs esošais mehānisms īsti pareizi nestrādā).

Microsoft SQL Server backup iespējas gan sniedzas tālāk par parastu rezerves kopiju veidošanu (piemēram, transaction log backup-ošana), taču ikdienā lielākā daļa lietotāju izmanto šādu vienkāršotu pieeju.

Papildināts: MSSQL rezerves kopiju veidošana

Remote desktop ar expired paroli

Windows iebūvētais Remote Desktop gaužām dīvaini strādā, ja lietotājam ir beidzies derīguma termiņš parolei. Tā vietā, lai konkrēti paziņotu par šo faktu vai pat piedāvātu paroli nomainīt, tiek izmests paziņojums: “An authentication error has occurred. The Local Security Authority cannot be contacted”. Risinājums ir pieslēgties pie datora vai servera lokāli un nomainīt paroli.

Remote Desktop drošība ar SSL sertifikātu

Remote Desktop (jeb Terminal Services) protokols ar katru Windows versiju lēnām attīstās. Pēdējās versijās (sākot ar Windows Vista) krietni uzlabota ir arī protokola drošība – pirms savienojuma izveides tiek pārbaudīta servera (ar serveri domāts dators, pie kura slēdzas klāt, tam nav obligāti jābūt ar servera operētājsistēmu) identitāte. Aktīvajā direktorijā problēmu ir maz – identitāti pārbauda, izmantojot domēna līdzekļus (Kerberos autentifikāciju).

Šo identitātes pārbaudi gan var atslēgt sistēmas uzstādījumu attiecīgajā sadaļā. Tas ļauj pie datora pieslēgties izmantojot vecākas Remote Desktop klienta versijas, piemēram, tās, kas iekļautas Windows XP.Drošības līmeņa uzstādījumi

Ja servera identitātes pārbaude ir atslēgta (vai serveris to neuztur), tad jaunās klienta versijas attēlos brīdinājumu, pirms vēl tiek prasīts ievadīt lietotāja vārdu un paroli.
Brīdinājums, ja atslēgta identitātes pārbaude 

More...

E-pastu jaunumi uz miga.lv servera

Nesenā miga.lv programmatūras atjaunināšana uz SmarterMail 6.0 izraisīja mēstuļu filtra nekorektu darbību, tika veikta nozīmīga izmaiņa mēstuļu filtrēšanā – ieviests greylisting (wikipedia). Īsumā – šis filtrs nepazīstamu sūtītāju e-pastus pirmajā reizē noraida. Īstie sūtītāji vienmēr mēģina vēlreiz, bet mēstuļu sūtītāji taupa savus resursus un atkārtoti vēstuli nosūtīt mēģina gaužām reti.

Šis filtrs uzreiz akceptē visus sūtītājus, kas atrodas Latvijā – pagaidām mēstules no Latvijas datoriem tiek sūtītas gana reti, kā arī dažādus populārākos e-pastu servisus, piemēram, gmail. Tādēļ galvenie cietēji ir dažādas tīmekļa lapas, kas, piemēram, sūta foruma reģistrācijas apstiprinājumus. Šie apstiprinājumi tagad var kavēties līdz pat 15 vai 30 minūtēm, atkarībā no sūtītāja.

Labā ziņa ir tā, ka katrs lietotājs savos uzstādījumos šo filtru var atslēgt, ja, piemēram, nepieciešams steidzami saņemt minēto reģistrācijas apstiprināšanas e-pastu.

Papildus šim jauninājumam šodien tika atjaunināta programmatūra uz SmarterMail 6.1.3518 versiju (izmaiņu saraksts), kurā solīta mēstuļu filtra SpamAssassin darbības uzlabošanās. Šī filtra sliktā darbība bija galvenais iemesls, kāpēc pēdējās pāris nedēļās mēstuļu atpazīšana bija tik sliktā līmenī.

Nobeigumā daži attēli, kas parāda greylisting noderīgumu.

Ienākošo mēstuļu skaits pa dienām (te gan jāņem vērā, ka pēdējās nedēļās daļa mēstuļu netika atpazītas):
Ienākošo mēstuļu skaits

Kopējais ienākošo un izejošo e-pastu skaits pa dienām:
Ienākošo un izejošo e-pastu skaits

Izejošo SMTP savienojumu skaits pa dienām (parāda, cik daudz savienojumu agrāk tika veidoti, lai paziņotu kādam citam serverim, ka mēstules adresāts nav atrasts):
Izejošo SMTP savienojumu skaits

IIS7 FTP SSL konfigurēšana

Nokonfigurēt IIS7 piedāvāto FTP protokola šifrēšanu, izmantojot SSL, nebija gluži tik elementāri, kā būtu gribējies. Ja neizmantotu FTP virtuālos hostus, tad viss būtu bijis vienkāršāk, bet diemžēl šoreiz tā nebija.

Viss it kā diezgan vienkārši - atveram FTP saitu un izvēlamies SSL sertifikātu. Nekā, piedzīvoju kļūdu: "534 Local policy on server does not allow TLS secure connections". Izrādās, SSL sertifikāts jānorāda nevis konkrētam saitam, bet gan visam serverim. Principā jau loģiski, jo enkriptēšana ir nepieciešama vēl pirms tiek ievadīts lietotāja vārds.

Bet, norādot sertifikātu serverim, dabūju kļūdu "431 Failed to setup secure session." kā atbildi uz "PROT P" komandu. Te nu izrādījās, ka konkrētam saitam SSL sertifikāts tomēr ir vajadzīgs, lai nodrošinātu datu konekcijas enkriptēšanu.

Nobeigumā varbūt noderīgs links par FTP SSL konfigurēšanu ar visām bildītēm, kā arī pamācību, kā konfigurēt Windows iebūvēto ugunsmūri: Configuring FTP Firewall Settings.