Kategoriarkiv: Windows

Using PowerShell to connect to Office 365: Index was out of range

A while ago I got this rather annoying problem when I wanted to connect to Office 365 using PowerShell to administer my tenants. I have always connected using the classic connection script that can be found anywhere in internet. It looks like this, and had been unchanged for a couple of years:

$adminCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $adminCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking
Import-Module MSOnline
Connect-MsolService -Credential $adminCredential

When run, the script began to return this error a few months ago:

Import-PSSession : Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
At C:\Users\MYUSER\office365\powershell\Connect_to_MSOnline.ps1:3 char:1
+ Import-PSSession $Session -DisableNameChecking
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Import-PSSession], ArgumentOutOfRangeException
    + FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Microsoft.PowerShell.Commands.ImportPSSessionCommand

So what was wrong? The $session variable had the expected content, so I knew the New-PSSession command had finished without error, but still the Import-Session command threw the «Index was out of range» error.

At first, my suspiscion went to Microsoft and the everchanging Office 365 sphere. Could I have missed a notice saying I had to upgrade the Microsoft Online Services Sign-in Assistant? A quick check confirmed that I had the latest version, but I reinstalled it just to be safe. What about the Windows Azure Active Directory Module? Also the latest, but I reinstalled this one as well.

Still no go!

I then turned to the PowerShell version. I had upgraded to Windows 10 when it was released, and I am running PowerShell 5. I have a Windows 7 virtual machine where the connection script worked as it should, and this VM is running PS 4. I found no information indicating that the PS version should have anything to do with the problem, though.

So what else is the difference between the Windows 7 VM and my Windows 10 PC? Both are domain joined and in the same OU, so there are no computer GPOs that are only effective on one of the computers. But then I noticed that on the Windows 7 VM, I was logged in with a local account, not a domain account. Could there be a user GPO in effect? This got me thinking.

Then it dawned on me – AppLocker! We introduced AppLocker when we started our general Windows 10 deployment, and I had forgotten that they had tightened the screw with the AppLocker rules. Our AppLocker rules state that regular users are not allowed to run anything from the temp directories (C:\Windows\Temp, %TEMP% and %TMP%). This is to prevent malware to run on the computer, but it also means that files that are downloaded when the Import-Module command is run can’t execute, and the session won’t be imported.

So how can I work my way around this AppLocker policy, being a regular user? If a regular user could change the AppLocker rules locally, that would render the rules pointless. So I have to find another way to make my script run.

The solution: If I can’t run anything from the temp directory, could I possibly redirect where the script thinks the temp directory is located? It was worth a shot.

Luckily, our AppLocker rules state that all users can run their problematic «special» programs from a predefined directory. Let’s just call it C:\Approved for now. I can manipulate the $env:temp variable inside the script, so the Import-Module command downloads it’s files to C:\Approved just for this script. You could use any other directory where regular users have write and execute access.

So I added a single line to the top of my connection script:

$env:tmp = «C:\Approved»

Then I held my breath and ran the script.

Eureka! The script ran beautifully! The module is downloaded and imported (I can see the files on the disk), and all cmdlets are available.

When the module is downloaded, it now creates a temporary directory inside the C:\Approved directory. This directory is given a name that starts with «tmp_» followed by 8 random characters and a random 3 character extension. Inside the directory three files are created. These three files have the same random name with .ps1xml, .psd1 and .psm1 extensions.

So will I have hundreds of randomly named directorys in my C:\Approved directory after a while? No, when I close my PowerShell session with the command «Get-PSSession | Remove-PSSession» or simply by closing PowerShell ISE, the directory and files are deleted automagically. Nice!

So that’s it. That is how I got my connection script running again…

Windows 7 – første episode

windows7logoI dag fant jeg ut at det var på tide å installere og sjekke ut Windows 7, så jeg fant fram en gammel PC (P4 3.0 GHz, 1 GB minne, 40 GB disk) og brant ut ISOen av Windows 7 på en DVD. Deretter var det bare å restarte maskinen og se hva som skjedde.

Og hva skjedde? Maskinen begynte installasjonen, men stoppet opp etter partisjonering av disken, når filkopieringen skal begynne. Jeg testet flere ganger, og hver gang stoppet den på samme sted. En kjapp test avslørte til slutt at det er en feil på harddisken på den maskinen jeg hadde funnet fram. Bummer!

OK, nytt forsøk med ny maskin – denne gangen min trofaste ThinkPad T42 (Mobile Pentium 1.6 GHz, 4GB minne,100 GB disk, intel a/b/g WLAN). Jeg koblet den til, skrudde den på, fortet meg med å legge inn DVDen med Windows 7 og ventet spent på hva som ville skje.

Så ble jeg positivt overrasket. Velger man norsk tastatur og tid-/datoformat og eller aksepterer standardinnstillingene som foreslås så foregår innstallasjonen hurtig og uten spørsmål som kan gi nybegynnere panikk. Dette må ha vært den raskeste Windows-installasjonen jeg har foretatt på lenge, og alt av maskinvare ble gjenkjent og fungerte uten problemer. Selv Ubuntu 8.10–installasjonen jeg foretok på den samme Thinkpaden før jul tok lenger tid og krevde mer interaksjon og kunnskap enn Windows 7-installasjonen.

Foreløpig har jeg ikke rukket annet enn å installere Windows 7 og teste noen få programmer. Lenovo System Update og Microsoft Update ble kjørt, og 5-6 oppdateringer ble funnet hos Microsoft og jeg kunne laste disse ned for installasjon. I den forbindelse oppdaget jeg noe ganske praktisk – på den nye taskbaren fungerer bakgrunnen på ikonet til den kjørende IE8-betaen som en nedlastingsindikator. Som med en vanlig «progress bar» fylte ikonets bakgrunn seg med grønt fra venstre mot høyre etterhvert som IE lastet ned filer. Kjekt! Ellers er det lett å se at Microsoft (som vanlig) har lånt endel fra konkurrentene sine – jeg kjenner igjen elementer fra både OSX og Ubuntu.

Ytelsesmessig så imponerer Windows 7 sammenlignet med Vista som jeg kjører på flere andre maskiner. Også sammenlignet med XP var ikke Windows 7 veldig mye tregere. Det ser ut til at Microsoft har tatt til seg kritikken fra Vista-brukerne, og det lover godt for det endelige produktet når det er klart. Trolig kommer RTM-versjonen allerede i juli, i følge Ed Bott hos ZDNet. Andy Patrizio hos InternetNews er enda mer optimistisk og antyder release allerede i juni 2009

Forhåpentligvis får jeg installert flere programmer og foretatt en grundigere test av Windows 7  innimellom andre arbeidsoppgaver i løpet av de neste ukene. Fungerer det greit så vurderer jeg seriøst å erstatte Windows Vista med Windows 7 beta 1 på «produksjonsmaskinen» på jobb i løpet av en måned eller to. Vista er tregt på en P4 3,2GHz med 4 GB minne, mens (de begrensede) erfaringene samt andres rapporter angåene Windows 7 ser lovende ut rent hastighetsmessig.

Windows Server 2008 – Startmenyens design

Jeg har lagt meg til den vanen å logge ut fra de Windows-serverne jeg administrerer når jeg er ferdig med hver jobb. Jeg liker ikke å ha sesjoner åpne (dvs å lukke RDP uten å logge av), og velger derfor aktivt at jeg vil logge av.

Etter å ha oppgradert et par servere til Windows Server 2008 merker jeg meg en ganske skummel nyhet – menyen har fått Vista-utseende. Det høres kanskje ikke så ille ut, men problemet er at man veldig lett tilgjengelig har fått en knapp for å skru av serveren. Er det én ting man gjerne ikke vil gjøre med en server som står i produksjon, så er det å skru den av.

Her er standard startmeny slik den ser ut etter fersk installasjon av Windows Server 2008 Standard:

For å logge av må man først trykke på Start, flytte seg forbi knappene med «Shut down» og «Lock«, åpne undermenyen, navigere seg forbi «Shut down» (igjen!), «Restart» og «Lock» (igjen!) for så finne «Log off» øverst i undermenyen. Her kan ikke Microsoft ha tenkt veldig langt. Hvor ofte vil man egentlig stanse eller restarte en server kontra det å logge av? Ikke veldig ofte, vil jeg tro. Det ville vært mye mer praktisk å endre «Shut down» til «Log off» for den venstre knappen (til venstre for «Lock«).

Heldigvis blir man spurt om man virkelig vil skru av eller restarte maskinen hvis man skulle trykke feil. Og heldigvis har de ihvertfall klart å kvitte seg med de to Vista-alternativene «Sleep» og «Hibernate» – to andre ting man sjelden ønsker at en server skal gjøre. Det er mulig å endre «Shut down«-knappen til «Hibernate» via «Power Settings» i kontrollpanelet, men jeg kan ikke se mange fornuftige grunner til å ville gjøre noe sånt. Det ville være mye mer logisk om man også kunne velge «Log off» som et alternativ. En server skal tross alt stå og gå, ikke stoppe eller gå i dvale.

Det man bør gjøre for å unngå å trykke på «Shut down» er å velge klassisk startmeny, som er en mye enklere startmeny (med aner helt tilbake til Windows 95). For å velge klassisk startmeny høyreklikker du på et ledig område på oppgavelinjen og velger menyvalget «Properties«, etterfulgt av skillearket «Start Menu» i vinduet som åpnes. Her kan du velge «Classic Start menu«.

Du får da en meny som ser ut som dette:

Den klassiske startmenyen har fremdeles valget «Shut Down» som første menyalternativ, men så kommer det etterlengtede «Log Off <user>«. Her kan man enkelt logge av serveren, uten å grave i undermenyer for å finne det man er på jakt etter. Et mye bedre alternativ, selv om man ofrer blant annet søkefeltet ved å velge denne menyvisningen.

Windows XP Service Pack 3 revisited

OK, mitt første møte med Service Pack 3 til Windows XP var en begredelig affære, men jeg kunne jo ikke la det være med det ene forsøket.

Ergo – fram med en annen maskin som hadde Windows XP med Service Pack 2, og se hva som skjer når Service Pack 3 blir installert. Denne gangen lastet jeg ikke ned SP3 selv, men lot Microsoft Update gjøre jobben for meg. Jeg skrudde på den aktuelle maskinen, startet opp Microsoft Update og ventet for å se om SP3 var tilgjengelig. Og det var den – den lå der og ventet og nærmest tagg om å bli installert. Akkurat som jeg hadde håpet.

Så da var det bare å sette igang. Backup er fremdeles for pyser, så jeg lot Microsoft Update laste ned og installere Service Pack 3 uten å se meg tilbake. Maskinen det skulle inn på var uansett relativt nyinstallert og hadde ikke noe brukerdata liggende.

Så hva skjer? Joda, jeg blir ledet gjennom de samme stegene som forrige gang, og alt går som forventet med installasjonen. Helt til slutt blir jeg bedt om å reboote, og det var jo her jeg fikk problemer med den andre maskinen.

Jeg puster tungt, og lar Windows restarte. Med dempet entusiasme ser jeg Windows avslutte, maskinen går gjennom sin POST, og Windows starter opp igjen. Akkurat som om ingenting har skjedd. Nesten litt skuffende, egentlig. Den eneste forskjellen jeg merker helt umiddelbart er at lyden på maskinen nå er på, den var av før jeg startet installasjonen. Bortsett fra det ser jeg ingen store forandringer, og må inn på "Min Datamaskin" og "Egenskaper" for å se at det står "Service Pack 3" der.

Status: Denne gangen gikk installasjonen helt smertefritt. Ikke noe å utsette på prosessen.

Benchmarking

Så da var det tid for å sammenligne noen tall, for å se om ting går raskere eller tregere enn før SP3 var på plass. Det jeg har testet er

  1. Oppstart (fra jeg skrudde på maskinen til innloggingsbildet var klart),
  2. Pålogging (fra jeg logget på og til Paint startet opp og var klar til bruk – jeg la den i Oppstart for å ha et sammenligningssgrunnlag), og
  3. Avslutning (fra jeg trykker på "Slå av" og til maskinen kutter strømmen.

Jeg testet tre fulle sykluser med skru på, logge inn og slå av, og før jeg startet hvert steg lot jeg maskinen stå i overkant av 30 sekunder for å roe seg og starte opp bakgrunnstjenester osv. Så pålogging skjedde først minst 30 sekunder etter at påloggingsvinduet var klart, og avslutning skjedde først minst 30 sekunder etter at Paint hadde åpnet seg og jeg hadde lukket det igjen. Før jeg tok tiden med Service Pack 3 gikk jeg gjennom 3 fulle sykluser med oppstart, pålogging og avslutning for å være sikker på at oppdateringen hadde "satt seg" og Windows var klar til bruk og ferdig med alt av opprydning, tilpasninger og annet etterarbeid. Og her er tallene:

Med Service Pack 2


1. forsøk
2. forsøk 3. forsøk
Oppstart 23,5 25 25
Innlogging 12 12 11,5
Avslutning 26 26 28

Med Service Pack 3

  1. forsøk 2. forsøk 3. forsøk
Oppstart 29 29,5 29
Innlogging 19 19 18,5
Avslutning 17 18,5 16

Tallsammenligning

Kort fortalt så bruker maskinen nå litt lenger tid på å starte opp og logge inn. Oppstart er i underkant av 25% tregere, og innlogging går omtrent 50% tregere. Avslutning derimot går raskere, rundt 30% raskere. Alle tall regnet ut i hodet, så vennligst ikke kom og arrester meg hvis jeg har regnet feil.

Konklusjon

På denne maskinen gikk installasjonen av Service Pack 3 helt smertefritt, og oppgraderingen har ikke medført de helt store endringene i responsen. At innlogging tar 19 vs 12 sekunder er godt målbart, men rent subjektivt er det neppe noen som mister nattesøvnen av 7 sekunders økt innloggingstid.

Og som alltid, YMMV. Ingen maskiner er like, så du kan ikke ta mine tall og automatisk regne med at de gjelder for din maskin.

Mine erfaringer med Windows XP Service Pack 3

Da var endelig Service Pack 3 til Windows XP ute, etter litt fram og tilbake med publisering, hurtig tilbaketrekking og påfølgende avisskriverier.

Hva er vel mer naturlig enn å teste programvaren, tenkte jeg, og lastet kjapt den ned fra adressen jeg fant i Computerworld Norge sin artikkel. Etter endt nedlasting var det bare å sette igang. Som nevnt i artikkelen om Vista SP1 så er jo backup bare for pyser, så jeg dobbeltklikket kjapt og greit på den nedlastede filen og holdt pusten.

Og problemene begynte med en gang. Her burde jeg kanskje tatt signalet, men må man teste, så må man teste. Feilmeldingen sa enkelt og greit følgende:

"Service Pack 3 cannot update a checked (debug) system with a free (retail) version of Service Pack 3 or vice versa."

Stort klarere kan man jo ikke si det, men jeg var like blank. Litt googling ga meg en mulig forklaring på problemet: Oppdateringspakken kan kun installere en "retail-SP" på "retail XP", og "checked-SP" på "checked XP". Pakken som var lastet ned var en checked versjon, og min XP-installasjon er en retail-installasjon. Derfor feilmeldingen.

Det er dog mulig å lure Windows, og det gjør man på denne måten (med engelsk XP, du får oversette selv):

  1. Velg FileRun – skriv inn "Regedit" og trykk Enter.
  2. Velg FileExport og lagre registeret for sikkerhets skyld.
  3. Gå til registernøkkelen HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion.
  4. Dobbeltklikk på verdien "CurrentType" for å redigere denne.
  5. Endre “Checked” til “Free”, eller  eventuelt “Multiprocessor Checked” til “Multiprocessor Free” hvis du har en multiprosessormaskin (Core2Duo regnes som multiprosessor utfra hva som sto i registeret hos meg).
  6. Lukk Regedit.

Nå kan du starte installasjonen av Service Pack 3.

For ikke å irritere dere med intetsigende skjermdumper av infovinduer skal jeg gjøre en lang historie kort: Man blir veiledet gjennom en serie vinduer, hvor alt man gjør er å akseptere betingelser og sitte og se på. Man lider seg gjennom lisensbetingelser og informasjon om backup, installasjon, fullføring og cleanup, og helt til slutt blir man bedt om å reboote maskinen.

MERK: Før du rebooter går du gjennom de seks stegene listet ovenfor og reverserer punkt 5. Så kan du reboote.

Så da gjør man vel det – rebooter altså. Jeg også. Og venter spent…

Jeg ser at maskinen rebooter, Windows XP sin splash screen vises i 10 sekunder, og så blafrer en BSOD over skjermen før maskinen restarter.

Og booter Ubuntu! Dette fordi jeg hadde testinstallert Ubuntu 8.04 i forrige uke, og grub booter Ubuntu som standard. Klarere kan det vel ikke sies? Dropp Windows og bruk Ubuntu!

Neida, problemer er til for å løses, så jeg rebootet igjen og valgte at Windows skal starte opp. Og får den illevarslende skjermen hvor man kan velge "Safe mode", "Safe mode with networking", "Safe mode with command prompt" osv. Jeg prøver å velge "Last known good configuration" uten hell. Og maskinen rebooter seg inn i Ubuntu en gang til. Jeg glemte enda en gang å velge at jeg vil inn i Windows. Høyere makter vil visst ikke la meg slippe taket i Ubuntu.

Ny reboot, og inn i Windows sin "her-gikk-noe-galt-bootmeny" enda en gang, og nå velger jeg "Safe mode". Her skal det repareres, og jeg henter over drivere osv fra den stasjonære maskinen for å sørge for at jeg har siste versjon av alt slikt for sikkerhets skyld. Og oppdager at alle stort sett alle drivere nå for tiden installeres med Windows Installer, og denne lar seg ikke kjøre i Safe mode. Så det kan jeg glemme. Jeg pakker ut hver enkelt driver og prøver med med bakveien – inn i Device Manager, høyreklikke på hver enhet jeg har oppdatert driver til og velge "Update driver". Etter at par feilslåtte forsøk innser jeg at selv på denne måten brukes Windows Installer. Ei heller høyreklikk på inf-filene og velge "Install driver" gir meg noe fornuftig.

I koffeinrus tyr jeg til Internet Explorer og Windows Updates etter å ha bootet meg inn i "Safe mode with networking), bare for å oppdage at ei heller dette er noen stor suksess. Supporten hos oss har disablet Windows Updates mot Microsoft sin server og kjører mot en lokal server. Dette er styrt med en Group Policy, og jeg orker ikke begynne å stresse med registeret for å prøve å pusle meg tilbake til en fullt fungerende Windows Update som kjører mot Microsoft. Windows Update kjører jo uansett Windows Installer når noe installeres, så det ville neppe fungert uten enda mer fikling i registeret.

Da gjenstår bare en ting: Avinstallasjon av Service Pack 3. Heldigvis er dette fullt mulig, og det går overraskende kjapt sammenlignet med tilsvarende operasjon med tidligere service packs. Og så blir jeg bedt om å reboote…

Den oppmerksomme leser vet nå hva som kommer til å skje, og det skjer: Ubuntu booter igjen, fordi jeg snudde meg vekk og jobbet litt på en annen maskin mens testmaskinen bootet. Så jeg må boote enda en gang. Og denne gangen husker jeg at jeg må velge Windows XP, og VOILA! så starter faktisk maskinen opp som den var før jeg begynte mine eskapader med Service Pack 3.

Så hva er konklusjonen av dette eventyret? Jo, jeg ser to muligheter:

  1. Ut med disken med Windows XP (og Ubuntu), og inn med Vista-disken min. Maskinen kom med preinstallert Vista Ulitmate, og den fungerte egentlig helt fint.
  2. Jeg beholder disken og lar grub fortsette å boote Ubuntu som standard. Og jeg beholder Ubuntu som arbeidsflate.

Jeg har en mistanke om at jeg velger punkt 1, men installerer nok Ubuntu også på Vista-disken så jeg gradvis kan la tanken om en maskin kun med Ubuntu modnes mens jeg leker/tester…

Uansett orker jeg neppe å fortsette med sentralstyrt Windows XP. Det er behagelig i endel tilfeller (skreddersydd programvaredistribusjon), men det er også en skikkelig pine av og til (fordi jeg ikke har fulle admin-rettigheter og fordi endel ting er låst ned av GPOer.

And that concludes todays lesson. Nå logger jeg av om en halvtimes tid og tar meg en seiltur. Jada, i dag starter årets serie med onsdagsregattaer, og jeg gleder meg som et lite barn!