Så, hvilke metoder for å distribuere programvaren vår tilbyr 1C oss?

1. Installasjon ved hjelp av påloggingsskript

2. Installasjon ved å plassere den i en delt nettverkskatalog

3. Installasjon vha gruppepolicyer

Vi avviser de to første metodene, fordi I denne artikkelen skal vi se på installasjon ved hjelp av gruppepolicyer (GPO).

Informasjonen på 1C:ITS-sidene som produsenten tilbyr oss om distribusjon av produktet ved hjelp av gruppepolicyer, er svært sparsom:

Når du installerer via gruppepolicyer, for å spesifisere installasjonsspråket, må du spesifisere riktig språktransformasjonsfil. Filnavn tilsvarer LCID desimalnotasjon Microsoft Windows(med filtypen .mst). Transformasjonsfilen for det russiske språket heter 1049.mst.

I tillegg må du spesifisere transformasjonsfilen adminstallrestart.mst. I dette tilfellet vil 1C:Enterprise-systemet, hvis klient- og serverversjonene ikke samsvarer, be deg om å starte datamaskinen på nytt for installasjon ny versjon. Administratoren må sørge for at den nye distribusjonen allerede er lagt til i gruppepolicyer.

Ved å bruke gruppepolicyer kan du installere flere versjoner av 1C:Enterprise.

For å installere en ny versjon må du opprette ny installasjon i gruppepolicyer.

1049.mst er åpenbart, men adminstallrestart.mst er ikke særlig nyttig. Derfor vil vi lage vår egen transformasjonsfil.
Først av alt vil jeg gjerne forstå hvordan vi kan indikere for installatøren hvilke komponenter av produktet vi ønsker å installere og hvilke vi ikke gjør? Til tross for at dokumentasjonen fra 1c generelt er ganske omfattende og detaljert, er det av en eller annen grunn ikke sagt et ord om dette. Men påloggingsskriptet, som vi avviste helt i begynnelsen, vil hjelpe oss å komme oss ut av denne situasjonen. I skriptet kan vi se følgende linjer:

CmdLine = cmdLine & " DESIGNERALLCLIENTS=1 THINCLIENT=1 WEBSERVEREXT=0 SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=1 LANGUAGES=RU"

Hvor:
DESIGNERALLCLIENTS – alle klienter og konfigurator.
THINCLIENT er en tynn klient for klient-server-drift.
THINCLIENTFILE – tynnklient med mulighet til å jobbe med filinfobaser.
SERVER – 1C:Enterprise server. Hvis installasjonsprogrammet kjøres fra startprogrammet, vil serveren bli installert som en applikasjon.
WEBSERVEREXT – utvidelseskomponenter for webserveren.
CONFREPOSSERVER – 1C:Enterprise-konfigurasjonslagringsserver.
SERVERCLIENT – komponenter for å administrere en klynge med 1C:Enterprise-servere.
CONVERTER77 – omformer informasjonsbaser fra versjon "1C:Enterprise 7.7".
SPRÅK – liste over grensesnittspråk for installasjon. Hvis flere språk er spesifisert, er de oppført atskilt med "",.

Denne linjen i skriptet genererer en kommandolinje som vil bli sendt til msiexec-installasjonsprogrammet for behandling.

For å lage en transformasjonsfil trenger vi "Orca"-editoren. (http://www.technipages.com/download-orca-msi-editor)
Og så, etter installasjon, starter vi programmet. "Fil" – "Åpne", og velg "1Centerprise 8.msi" fra 1C-distribusjonssettet. En liste over tabeller dukket opp på venstre side av programmet, og tabellverdier dukket opp til høyre. Fordi 1C selv anbefaler ikke å endre msi-pakken, så vi går til "Transform" - "New Transform" -menyen.

Du må gå til "Property"-tabellen. På høyre side ser vi etter linjen "DEFLANGUAGE", med verdien "Auto". Verdien må endres til "RU" (uten anførselstegn, selvfølgelig).

For de fleste brukere må du installere et minimum av komponenter, disse er tynnklient, tykk klient og språk (for eksempel russisk)
La oss derfor lage nye felt (Ctrl+R), der du må spesifisere et navn og en verdi.
DESIGNERALLCLIENTS = 1
THINCLIENT = 1
THINCLIENTFILE = 1
SERVER = 0
WEBSERVEREXT = 0
KONFREPOSSERVER = 0
SERVERKLIENT = 0
KONVERTER77 = 0
SPRÅK = RU

De. Det skal se ut som på bildene:

Deretter går du til "Transform"-menyen - "Generer Transform...". Lagre filen, kanskje i mappen med distribusjonen, for eksempel Client.mst
Dette fullfører genereringen av transformasjonsfilen.
For å sjekke installasjonen må du åpne "cmd"-programmet. Gå til distribusjonsmappen. Og kjør kommandoen:
setup.exe /S TRANSFORMS=Client.mst TRANSFORMS =1049.mst
eller
msiexec /i "<каталог с дистрибутивом >"TRANSFORMER="<каталог с дистрибутивом >"\Client.mst TRANSFORMS="<каталог с дистрибутивом >"\1049.mst/passiv

I den første kommandoen betyr parameteren "/S" og i den andre kommandoen parameteren "/passiv" at installasjonen vil foregå i bakgrunnen.

Etter en stund kan du sjekke. Tykk klient, tynn klient og russisk grensesnitt bør installeres.

Deretter må du opprette en ny installasjon i domenegruppepolicyer.
Du må også lage generell katalog på nettverket ditt hvor de vil bli lagret installasjonsfiler. Sjekk at domenebrukere har leserettigheter fra denne katalogen.
Åpne GP-editoren. Vi lager en ny politikk. Åpne den for redigering. Gå til delen "Datamaskinkonfigurasjon" - "Installere programmer".

Vi skaper ny pakke. Vi velger filen 1CEnterprise 8.2.msi, banen til filen må spesifiseres gjennom nettverksmiljøet \\SRV\…..\1CEnterprise 8.msi, vi velger distribusjonsmetoden - en spesiell, slik at modifikasjoner kan gjøres .

Etter å ha opprettet pakken, åpnes vinduet for pakkeegenskaper.
Du må gå til "Endringer"-fanen og legge til en transformasjonsfil for det russiske språket kalt 1049.mst og en transformasjonsfil Client.mst.

Etter at du har klikket på "OK", vil det ikke være mulig å legge til modifikasjonsfiler.
Pakken er klar. Det er verdt å merke seg at pakken må brukes på en gruppe datamaskiner for å gjøre dette, må du opprette en slik gruppe i AD og plassere datamaskinene som installasjonen er ment for der.

Når du installerer eller oppdaterer et 1C Enterprise-program, står mange administratorer overfor umuligheten av å utføre disse oppgavene riktig ved å bruke gruppepolicyer. Den vanligste feilen er 1720:

Produkt: 1C:Enterprise 8.1 - Feil 1720. Det er et problem med denne Windows Installer-pakken. Et skript som kreves for at denne installasjonen skal fullføres, kunne ikke kjøres. Kontakt støttepersonellet eller pakkeleverandøren. Tilpasset handling customDetectPrevVersion skriptfeil -2147467259, Msi API-feil: ProductInfo,Product,Attribute Line 7, Column 5

Denne feilen er forårsaket av feil bruk av programoppdateringsmekanismen, det vil si at vi ikke kan installere en ny versjon på toppen av den installerte forrige versjonen.

For å utføre oppdateringen må du manuelt redigere installasjons-msi-filen før du oppretter gruppepolicyen. For å gjøre dette bruker vi Microsofts gratis msi-filredigeringsverktøy kalt Spekkhugger. Dette verktøyet er en del av Microsoft Windows Software Development Kit (SDK), og kan også lastes ned separat.

  1. Last ned og installer Spekkhugger;
  2. Åpne filen med programmet 1Centerprise 8.1.msi
  3. Vi finner delen " Custom Action"og i den parameteren" customDetectPrevVersion". Slett denne parameteren og lagre endringene;
  4. Kopier til offentlig nettverksmappe distribusjonen som for øyeblikket er installert (hvis vi oppdaterer bygget) og den nye versjonen 1C med msi-filen vi modifiserte. Vi kopierer naturligvis til forskjellige mapper

Nå må vi lage en gruppepolicy og lage i delen " Installere programmer» to installasjonspakker - gamle (for eksempel 8.1.11) og nye (8.1.13) versjoner (fig. 2).


Deretter, i egenskapene til installasjonspakken til den nye versjonen av 1C, må vi indikere at denne pakken utfører en oppdatering gammel versjon 8.1.11 (fig. 3). Etter å ha tildelt en policy, kan det være nødvendig med en ekstra omstart av datamaskinen, siden fjerning av den gamle og installasjonen av de nye programvareversjonene ikke er synkronisert.

Ved å bruke gruppepolicyer kan du installere flere versjoner av 1C:Enterprise.
For å installere en ny versjon, må du opprette en ny installasjon i gruppepolicy.

Når du installerer via gruppepolicyer, for å spesifisere installasjonsspråket, må du spesifisere riktig språktransformasjonsfil. Filnavnene tilsvarer Microsoft Windows desimal LCID-representasjonen (med filtypen .mst). Transformasjonsfilen for det russiske språket heter 1049.mst.
I tillegg må du spesifisere transformasjonsfilen adminstallrestart.mst. I dette tilfellet vil 1C:Enterprise-systemet, hvis klient- og serverversjonene ikke samsvarer, be deg om å starte datamaskinen på nytt for å installere den nye versjonen. Administratoren må sørge for at den nye distribusjonen allerede er lagt til i gruppepolicyer.

Du må opprette en delt katalog på nettverket der installasjonsfilene vil bli lagret. Sjekk at domenebrukere har leserettigheter fra denne katalogen.
Åpne GP-editoren. Vi lager en ny politikk. Åpne den for redigering. Gå til delen "Datamaskinkonfigurasjon" - "Installere programmer". Et eksempel er vist i Windows Server 2008 R2.

La oss lage en ny pakke. Vi velger filen 1CEnterprise 8.2.msi, banen til filen må spesifiseres gjennom nettverksmiljøet \\SRV\…..\1CEnterprise 8.2.msi, vi velger distribusjonsmetoden - spesiell, slik at modifikasjoner kan gjøres.

Etter å ha opprettet pakken, har jeg omtrent 30 sekunder, vinduet for pakkeegenskaper åpnes.

Du må gå til "Endringer"-fanen og legge til en transformasjonsfil for det russiske språket kalt 1049.mst og en transformasjonsfil adminstallrestart.mst. Det skal se slik ut:

Etter at du har klikket på "OK", vil det ikke være mulig å legge til modifikasjonsfiler.

Pakken er klar. Det er verdt å merke seg at pakken må brukes på en gruppe datamaskiner for å gjøre dette, må du opprette en slik gruppe i AD og plassere datamaskinene som installasjonen er beregnet på.

I nærheten av rektor 26. juli 2014 kl. 13:09

Koble til 1C 8-databaser ved hjelp av AD/GPO

  • Systemadministrasjon

God ettermiddag

Inspirert av et nylig innlegg, vil jeg dele en alternativ løsning på dette problemet:

  • uten å bruke skript
  • uten å redigere 1C-filer (ibases.v8i, 1CEStart.cfg)
Automatiseringsoppgavene er like: det er mange 1C-databaser og en AD-katalog er det nødvendig for en bruker som er i en bestemt AD-gruppe å få muligheten til å starte en bestemt 1C-database.

Denne metoden er praktisk bare hvis brukeren arbeider med et lite antall 1C-databaser (fra en til ti), siden den innebærer å plassere en egen snarvei på skrivebordet for hver database.

Trinn 1.

La oss lage en gruppe i AD som inkluderer en liste over datamaskiner som 1C-klienten er installert på - den vil inkludere terminalfarmservere, så vel som datamaskiner som 1C-klienten er installert på. Faktisk er dette kanskje ikke nødvendig, men vi vil bruke denne gruppen som et ekstra filter:

Trinn 2.

La oss lage grupper i AD for 1C-databasebrukere:

Du kan legge merke til at en egen gruppe er opprettet for å starte databasen med andre parametere (i dette tilfellet i tykk klientmodus).

Trinn 3.

Opprett en gruppepolicy som kontrollerer brukersnarveier:

Dessverre, for 1C er det ennå ikke en klientversjon for x64-plattformen, så standardplasseringen til klienten avhenger av bitheten til plattformen. For versjon 1C 8.3 på 32-biters versjon Windows-klient installert i %ProgramFiles%\1cv8\common\1cestart.exe, og på 64-biters Windows - %ProgramFiles(x86)%\1cv8\common\1cestart.exe

La oss nå se nærmere på opprettelsen av hvert element.

På fanen "Generelt" angir du parametrene for tilkobling til databasen og plasseringen av snarveien (i dette tilfellet skrivebordet). Et eksempel på å lage en snarvei for Win x64-plattformen

En liten digresjon for de som bare planlegger å migrere fra 1C 8.2-plattformen til 8.3:

I fanen "Generelle innstillinger", la oss målrette snarveien mot de tidligere opprettede AD-gruppene:

Innstilling for Win x86-plattformen:

Og for Win x64:

Addisjon ny base kommer ned til å skape ny gruppe AD, kopierer snarveien til GPO og redigerer tilkoblingen til databasen.

P.S. Hvis du har ansatte som uavhengig plasserer snarveier på skrivebordet, er det bedre å ikke bruke denne metoden for å få tilgang til databaser.

Takk for oppmerksomheten, jeg håper dette innlegget vil være nyttig for deg.

Tagger: 1c, annonse, gpo, lenker

På en eller annen måte forlot jeg min koselige. Jeg korrigerer meg selv. I dag skal vi snakke om å installere 1c v8.2 i et bedriftsmiljø ved å bruke gruppepolicyer. Så, hvilke metoder for å distribuere programvaren vår tilbyr 1C oss?

  1. Installasjon ved hjelp av gruppepolicyer

Vi avviser de to første metodene, fordi for å bruke dem må brukeren ha lokale administratorrettigheter (dette er ikke våre metoder). Det ville være mulig å bruke skriptet som et oppstartsskript, med et lite tillegg til det. Men for å være ærlig forstår jeg ikke: hvorfor bruke et skript når du har standard evne til å distribuere en applikasjon fra en msi-pakke ved å bruke gruppepolicyer. Det ser ut som enda et trivielt tilfelle av programvaredistribusjon i et domene. La oss nå gå til produsentens nettsted, lese om hvordan du setter opp en msi-pakke, kanskje til og med laste ned noen verktøy for å lage en transformasjonsfil (mst-fil), slik det er vanlig store produsenter programvare, og jobben vil bli gjort. Dette var imidlertid ikke tilfelle. Informasjonen som produsenten tilbyr oss om distribusjon av produktet ved hjelp av gruppepolicyer, er svært mager:

Når du installerer via gruppepolicyer, for å spesifisere installasjonsspråket, må du spesifisere riktig språktransformasjonsfil. Filnavnene tilsvarer Microsoft Windows desimal LCID-representasjonen (med filtypen .mst). Transformasjonsfilen for det russiske språket heter 1049.mst.

I tillegg må du spesifisere transformasjonsfilen adminstallrestart.mst. I dette tilfellet vil 1C:Enterprise-systemet, hvis klient- og serverversjonene ikke samsvarer, be deg om å starte datamaskinen på nytt for å installere den nye versjonen. Administratoren må sørge for at den nye distribusjonen allerede er lagt til i gruppepolicyer.

Ved å bruke gruppepolicyer kan du installere flere versjoner av 1C:Enterprise.

For å installere en ny versjon, må du opprette en ny installasjon i gruppepolicy.

Selskapet 1c ga oss et veldig merkelig sett med informasjon: informasjon om transformasjonsfilen 1049.mst er åpenbar, men informasjon om adminstallrestart.mst er ikke særlig nyttig. Først av alt vil jeg gjerne forstå hvordan vi kan indikere for installatøren hvilke komponenter av produktet vi ønsker å installere og hvilke vi ikke gjør? Til tross for at dokumentasjonen fra 1c generelt er ganske omfattende og detaljert, er det av en eller annen grunn ikke sagt et ord om dette. Men påloggingsskriptet, som vi avviste helt i begynnelsen, vil hjelpe oss å komme oss ut av denne situasjonen. I skriptet kan vi se følgende linjer:

cmdLine = cmdLine & “THICKCLIENT=1 THINCLIENT=1 WEBSERVEREXT=0 SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=0 LANGUAGES=RU”

Denne linjen i skriptet genererer en kommandolinje som vil bli sendt til msiexec-installasjonsprogrammet for behandling. Som vi kan se, er parametere i formen "Property=PropertyValue" lagt til denne linjen. Det vil være rimelig å anta at hver av disse egenskapene skal gjenspeiles i egenskapstabellen til msi-pakken. Etter å ha sett på msi-pakken ved hjelp av Orca-editoren (som allerede er skrevet om på bloggen min), så jeg ingen av disse egenskapene i 1c-pakken. Derfor, bare i tilfelle,.

Så vi må legge til flere rader i egenskapstabellen som inneholder de tilsvarende egenskapene og deres verdier. Vi vil selvfølgelig ikke gjøre endringer direkte i selve installasjonspakken (msi-fil), men vil klargjøre en transformator (mst-fil) ved hjelp av Orca. Skjermbildet viser endringene som må gjøres i installasjonspakken for å indikere at vi bare vil installere de tykke og tynne klientene og samtidig velge det russiske språket for grensesnittet (ikke glem at vi ikke bare må velg det russiske språket for grensesnittet, men legg det også til installasjonspakken ved å bruke riktig transformator - fil 1049.mst). Jeg vil ikke snakke om hvordan du legger til en installasjonspakke og modifikasjonsfiler (transformasjonsfiler) i gruppepolicy, jeg håper du vet dette, og hvis du ikke vet, så kan du det.

Det gjenstår å vurdere spørsmålet om å legge til informasjonsbaser til listen som brukeren vil se når du starter 1c-programmet. Heldigvis, siden 1c v 7.7. mye har endret seg, og du trenger ikke å redigere registeret for dette. Informasjon om databaser er nå lagret i en fil med utvidelsen v8i. Som standard er filen plassert på lokal datamaskin i en mappe %APPDATA%\1C\1CEStart og har et navn ibases.v8i. , men det er noen begrensninger knyttet til det faktum at *.v8i-filer er filer i unicode-formatet, og GPP kan ikke fungere med filer i unicode-koding. Derfor må vi inngå kompromisser, noe du kan lese om i Sergeis blogg. Men det er en annen måte å lage en liste over infobaser for brukeren på, som ikke har denne ulempen. Fra og med v8.1 ble det i 1c mulig, etter å ha registrert en infobase i listen "for hånd", å laste opp en beskrivelse av hver infobase til en separat v8i-fil. Deretter kan disse v8i-filene plasseres på en delt nettverksressurs og legges til brukernes liste over delte infobaser. Og å vite at den generelle listen over infobaser er lagret i en fil 1CEStart.cfg, som ligger i mappen %APPDATA%\1C\1CEStart, kan du bruke GPP til disse formålene uten problemene som Sergey Betke møtte. Jeg vil gi et eksempel på innholdet i en enkel fil 1CEStart.cfg(en beskrivelse av filformatet finner du på nettstedet http://its.1c.ru, hvis du er den heldige eieren av et ITS-abonnement).