Auto Logon to Office 365 Sharepoint using VBS

On September 9, 2014, in Technology, by Mike Waldron

A client of mine has a SyncToy process which synchronizes Office 365 Sharepoint document library files to a local drive.  We map local drives to Sharepoint document libraries and then run SyncToy to copy the data locally.  A friend of mine helped me with this VBS script (thanks Nick), which automatically logs a user in and then maps the drives so we don’t have to deal with the 24 hour SAML token timeout, requiring a user to logon every 24 hours.  We use this script to automate our SyncToy procedure which runs throughout the day.

On Error Resume Next


Set objIE = CreateObject("InternetExplorer.Application.1")
Call objIE.Navigate("")

objIE.Visible = True

Do Until objIE.ReadyState = PAGE_LOADED : Call WScript.Sleep(500) : Loop

objIE.Document.all.Login.Value = ""
objIE.Document.all.Passwd.Value = "office365password"

'The "Submit" button needs to be "clicked" twice in order to sign the user in
' * It appears that some javascript needs to take place behind the scenes to properly initiate the logon
Call objIE.Document.getElementById("cred_sign_in_button").click
Call objIE.Document.getElementById("cred_sign_in_button").click


Do Until objIE.ReadyState = PAGE_LOADED : Call WScript.Sleep(500) : Loop

Set wShell=CreateObject("WScript.Shell")

NetCommand="net.exe use p: "" 1"" / office365password"
wShell.Run "cmd.exe /C " & NetCommand, 1, True

NetCommand="net.exe use w: "" 2"" / office365password"
wShell.Run "cmd.exe /C " & NetCommand, 1, True

Set wShell=Nothing


Set objIE = Nothing

Tagged with:  

I’ve recently been moving many clients to Office 365, and ran into a small problem for a particular client when performing a migration from an existing in-house Exchange server. Many users in the domain were failing migration, and gave the following error:

Failed to update one of the recipient properties. Couldn’t find a user or contact with identity “/o=Company/ou=First Administrative Group/cn=Recipients/cn=user”

This error in my case was caused by the manager field in the Active Directory being populated with the “user” common name (CN) quoted above.  Removing/clearing the manager field fixed the issue and once the migration batch was re-run the users got migrated just fine.  You can find the “Manager” field for a user in the “Organization” tab in Active Directory.

Thanks to Marcel at the MS Community forums for posting the fix!


Web Hosting