https://technet.microsoft.com/en-us/evalcenter/ff182914.aspx

Gleder meg til å se integrasjonen med SCCM 2007 og hvordan dette fungerer.

I forbindelse med et testoppsett har jeg publisert Sharepoint 2010 ut på Internet med UAG og tenkte det kunne være greitt å beskrive de stegene jeg gjorde.

1. Forutsetninger

Nå tar jeg utgangspunkt i en ferdig installert UAG (inkludert update 1 som har full støtte for Sharepoint 2010) som er medlem av domenet (jeg velger denne konfigurasjonen da dette også anbefales for TMG for sentral administrasjon og kontroll av OS med oppdateringer) og har registrert AD som autentiseringskilde (authentication and authorization server). Kjør gjerne UAG Best Practise Analyzer (BPA) som finnes her. Dette er en ganske rett frem sak ved installasjon og konfigurasjon av UAG så her er det like greitt å lese installasjonsbeskrivelsen på Technet. En annen forutsetning er at sertifikattjenestene er installert (Microsoft CA i mitt tilfelle) og klar til å utstede sertifikater. Til slutt må tjenestene du ønsker å publisere være adresserbare fra Internet.

2. Sertifikater

Første utfordring for mitt vedkommende var sertifikater (er ingen ekspert på dette, dessverre). Siden jeg ønsker å publisere flere tjenester ut av UAG var det nødvendig å lage et wildcard (*.domene.com) sertifikat som dekker underliggende navn og relaterte tjenester. Det er en god beskrivelse her på hvordan dette kan gjøres. Dette sertifikatet må importeres til UAG serveren, og skal brukes av https trunk oppsettet. Nå er det nok enda bedre å få generert et sertifikat fra en ekstern leverandør som GoDaddy eller lignende for å unngå advarsler, men for klienter sin del er det helt fint å importere root sertifikatet til testdomenet slik at kjeden kan verifiseres (dette er jo en testlab).

3. Lage en UAG https trunk

Så snart wildcard sertifikatet er importert til UAG serveren er vi klar for å lage en https trunk som sørger for sikker tilgang til de tjenester og applikasjoner som publiseres gjennom denne. Oppsett av UAG trunk er wizard dreven og her skal du utføre stegene:

• Step 1 – Select trunk type
  • Portal trunk
• Step 2 – Setting the trunk
  • Trunk name: ett eller annet navn
  • Public host name: offentlig addresserbar adresse
  • External web site
    • IP address: som da skal være definert
    • http port: 80 i mitt tilfelle
    • https port: 443 i mitt tilfelle
• Step 3 – Authentication
  • Add: i mitt tilfelle den registrerte domene kontrolleren
• Step 4 – Certificate
  • Server certificate: *.domene.com som er wildcard sertifikatet som ble laget tidligere og importert til UAG serveren
  • Får kanskje en advarsel her, men dette er et testoppsett så kjør på
• Step 5 – Endpoint security
  • Use Forefront UAG access policies
  • Har ikke satt opp NAP integrasjon så glem denne
• Step 6 – Endpoint policies
  • Ingen endringer her, men det er jo her dere kan definere veldig spesifikke kriterier for hva en klient skal være konfigurert til før den gis tilgang til UAG
• Completing the create trunk wizard
  • Finish!

4. Sharepoint oppsett

Å installere Sharepoint 2010 i er enkelt og greitt; ingen spesielle utfordringer her. Men, det jeg kludret med var riktig bruk av Alternate Access Mapping (AAM). AAM gjør at Sharepoint 2010 kan tilordne henvendelser til riktig web applikasjon (kan jo være flere av disse) og dermed gi riktig respons ut fra kallet. I mitt tilfelle ønsker jeg følgende:

• På Intranet brukes https://minsharepoint
• På Internet brukes https://minsharepoint.domene.com

Merk at på Internet brukes https protokollen, mens på Intranet brukes vanlig http (du kan selvfølgelig endre dette til https på Intranet). Fra Internet benyttes den ferdig definerte https trunken i UAG som da overfører transport videre til Sharepoint, som igjen selv utfører URL endringene ved hjelp av AAM. Dette sørger for at revers proxy som UAG, ikke behøver å endre innholdet i sidene som presenteres til eksterne kilder.

Offentlig adresse er for eksempel: uag.domene.com for selve UAG portalen og minsharepoint.domene.com for Sharepoint 2010 installasjonen dere ønsker å aksessere direkte uten å måtte gå om UAG portalen (må logge på uansett, men dette er mer transparent).

5. Publisering

Når så forarbeidet er utført er resten enkelt. Start Add Application Wizard i UAG og utfør stegene:

• Step 1 – Select Application

• Web: Microsoft Sharepoint Server 2010

• Step 2 – Configure Application

• Application name: minsharepoint

• Step 3 – Select Endpoint Policies

• Default verdier, men her er det uendelige muligheter for styring av krav til klienter som aksesserer UAG

• Step 4 – Deploying an Application

• Configure an application server (har ikke noen farm i mitt tilfelle)

• Step 5 – Web Servers

• Addresses: navn til intern sharepoint installasjon
• Paths: default verdi i mitt tilfelle
• Http port: 80 (bruker ikke https på Intranet)
• Public host name: minsharepoint.domene.com
• Resterende default verdier

• Step 6 – Authentication

• Select authentication servers: legg til server som autentiserer brukere, i mitt tilfelle en domenekontroller
• Resterende default verdier

• Step 7 – Portal Link

• Her kan du legge til beskrivende navn på UAG portalen og eventuelt bytte ikon

• Step 8 – Authorization

• Her styrer du hvem som skal ha tilgang til å aksessere Sharepoint fra Internet.

• Completing the Add Application Wizard

Referanser

Nå har jeg jo ikke funnet på alt dette selv, og de referansene jeg har brukt er en bloggrekke fra UAG gruppen i Microsoft og informasjon på Technet.

Men, det er noen viktige og gode lanseringer:

• System Center Service Manager 2010 – ITILv3 og MOF basert service desk er nå endelig RTM.
• System Center Data Protection Manager 2010 – avansert backup av blant annet Hyper-V (også Live Migration støtte), Exchange, Sharepoint, SQL, klienter med mer.
• System Center Essentials 2010 – en enserver løsning (tenk litt på Small Business Server) for overvåkning, adminstrasjon av Hyper-V, oppdateringer og applikasjonsutrulling beregnet for mindre og midlere bedrifter.

Det er tilgjengelig et opptak av Bob Muglia’s keynote som jeg anbefaler:(https://www.studiosevent.com/newscenter/?id=mms)

Den er på drøye timen, men tar for seg flere spesielt interessante områder:

• Dynamisk IT – status og veien fremover
• Azure – hvordan System Center kan integreres mot “skyen” ved administrasjon og overvåkning.
• Modellbasert administrasjon
• System Center Virtual Machine Manager v.Next

Her er det noen demonstrasjoner som virkelig viser hva Microsoft gjør for å lette administrasjonen av IT systemer, inkludert mot Azure.

Gleder meg til fortsettelsen.

På det eksisterende oppsettet hadde jeg blant annet en domenekontroller som jeg da greidde å kåle til slik at jeg mistet oppsettet (ikke VHD fila) og måtte sette den opp igjen på nytt.

Videre fikk den da en DHCP adresse siden innstillingene var borte og plutselig gadd den ikke å replikere med min andre domenekontroller. Fikk flere meldinger, men den verste var: “The destination server is currently rejecting replication requests”.

Prøvde å kjøre dcpromo for å fjerne feilende kontroller, men feilet, og jeg hadde ikke lyst til å kjøre i forced modus, med påfølgende rydding.

Et tips jeg fant til slutt var følgende:

repadmin /options SERVERNAVN -disable_inbound_repl

repadmin /options SERVERNAVN -disable_outbound_repl

Dette løste tilsynelatende problemene mine, men må holde et lite øye med serveren fremover for å se om det er noen andre problemer. Har jo System Center Operations Manager så det skal nok gå bra.

Den beste måten å forklare hensikten med PRO er gjennom eksempel:

Virtuell infrastruktur i dag er typisk bestående av fysiske servere (vert) som kjører flere virtuelle maskiner, eller gjester. Diskene til de enkelte gjestene er vanligvis plassert på en SAN i bakkant av vertene og kommuniserer med vertene over dedikerte kanaler (for eksempel fibre channel). Det er med andre ord flere komponenter her som er kritiske for å opprettholde stabil ytelse og høy oppetid. Her definert av vertene, kanalene og SAN. Vanligvis er dette komponenter fra forskjellige produsenter.

PRO kan her hjelpe ved at Microsoft nå har inngått samarbeide med flere aktører for at disse skal levere Management Packs (regelsett for overvåkning) til sine teknologier. Med R2 versjonen av OpsMgr og agentteknologi for overvåkning av Linux, Unix, AIX, HP-UX og Sun Solaris finnes følgende PRO Management Packs (ikke utfyllende) for produkter og fra partnere:

• HP
• Dell
• Apache Web Server
• MySQL
• Oracle (på Linux/Unix)
• EMC
• Emulex
• NetQOS
• QLogic
• Quest
• Bridgeways
• Brocade

OpsMgr er løsningen som utfører selve overvåkningen og kan, basert på hendelser avdekket av de enkelte Management Packs, sende PRO tips til VMM som igjen kan ta aksjoner på disse.

Eksempelvis: HP Management Pack som integrert med HP SIM kan avdekke om det er et maskinvareproblem, og om dette kan medføre degradering hvis servern kjører som en vertsmaskin. Skjermbildet under viser et diagram fra HP Management Pack.

Når så et problem er avdekket vil det bli sendt et PRO tips til VMM som tydelig forklarer hva som er skjedd og hva som kan gjøres.

Igjen et eksempel: HP SIM varsler om paritetsproblemer på en minnebrikke som da fanges opp i OpsMgr som en PRO relatert hendelse. Denne meldingen sendes videre til VMM som et PRO tips med beskjed om at virtuelle maskiner på vert med minneproblemer er anbefalt flyttet til en annen vert. Med i meldingen er også en “implement” knapp som kan initiere flyttingen.

I min konfigurasjon ville jeg teame 2 nettverkskort. Her er stegene jeg utførte for å komme til mål:

1. Installer Windows Server 2008 R2 RC og aktiver Hyper-V.
2. Installer siste PSP fra HP som da inkluderer NIC teaming konfigurasjonsverktøy. Siste PSP (09.07.09) for Proliant finner dere her. SNMP må være aktivert på server!
3. Når så PSP er installert på server, bruk ILO mot server og gå til \program files\hp\ncu\ og kjør hpteam.cpl. Jeg prøvde først via RDP hvor NIC teaming konfigurasjon feilet, men om det er fingertrøbbel eller bare ikke supportert er jeg ikke helt sikker på.
4. I GUI som kommer opp etter kjøring av hpteam.cpl, velg kort som skal være med i NIC teaming og klikk Team. Enkelt og greitt så langt.
5. Kontroller gjerne resultat i cmd med systeminfo hvor du vil få frem informasjon lignende skjermbildet under. Legg merke til at det er referert til to fysiske nettverkskort, en virtuell nettverkssvitsj (Hyper-V) og et virtuelt teaming kort.
6. Nå skal server samkjøre trafikk over de to kortene hvor siste steg er å få Hyper-V til å bruke NIC teaming nettverkskortet. Her har jeg brukt System Center Virtual Machine Manager for å utføre denne konfigurasjonen. Høyreklikk på host hvor teaming er aktivert, velg properties og åpne fanen for Networking. Legg til eller endre eksisterende virtuell nettverk til å bruke Connection “HP Network Team…”.

Til høyre ser dere Network Configuration for min maskin hentet ut fra System Center Virtual Machine Manager. Under ser dere konfigurasjonsbildet for nettverk vist for Hyper-V manager.

Lykke til!

Her er den i alle fall, kanskje jeg husker det nå…

Microsoft server software and supported virtualization environments

• Bruker opplever dette som svært behagelig ved at det ikke er behov for å aktivere en dedikert VPN forbindelse for tilgang til interne ressurser.
• Bedriftens IT systemer har tilgang til klienten slik at vedlikeholdsoppgaver kan utføres (for eksempel Group Policy og Network Access Protection (NAP)).
• Sømløs overgang mellom interne og eksterne ressurser. Typisk eksempel kan være når en e-post mottas som refererer til en intern side, så vil bruker med DirectAccess kunne gå direkte til denne interne siden uten å måtte starte en egen VPN sesjon.

Det er flere forutsetninger som må på plass for at DirectAccess skal virke, slik som at interne systemer som skal eksponeres mot DirectAccess kjører IPv6 (se forøvrig link referanse for IPv4), sertifikat infrastruktur for å understøtte autentisering og kyptering av trafikk til og fra klient (IPSec).

Men, hovedpoenget med denne posten er at Microsoft Forefront Unified Access Gateway (UAG) er en glimrende løsning for å eksponere DirectAccess ut av bedriftens nettverk.

UAG hjelper til med å nå IPv4 servere ved bruk av overgang mellom IPv4 og IPv6 (NAT-PT), høy tligjengelighet og skalerbarhet gjennom Network Load Balancing (NLB), forenklet oppsett og utrulling av DirectAccess, og ikke minst muligheten for å gi tilgang andre typer klienter til definerte interne ressurser (som er den opprinnelige funksjonen til UAG).

Oversikt finnes her: https://blogs.technet.com/edgeaccessblog/archive/2009/06/22/introducing-uag-directaccess-solution.aspx.

God lesing.

Mer informasjon her:

https://www.networkworld.com/news/2009/061109-ms-novell-linux-interop.html?hpg1=bn

Dette gikk ikke helt upåaktet hen og resultatet nå er at en ansatt ved VMWare har gått ut og beklaget videoen, samt trukket den tilbake.

Stoler vel ikke helt på enkelte typer informasjon fra VMWare etter dette, som enkelte analytikere sier.

https://blogs.technet.com/virtualization/archive/2009/06/12/vmware-fud-fiasco-final.aspx

Les og bedøm selv.