Friday, July 10, 2015

Office 365 Confirm last password change time for users

Open Powershell as Administrator

Run the following:

Connect-MSOLservice

clip_image001

Get last password change time:
get-msoluser |fl displayname,lastpasswordchangetimestamp

clip_image002

You can export it to a file as well:
get-msoluser |fl displayname,lastpasswordchangetimestamp >c:\passchange.txt

Office 365 Force Password Sync for accounts not updating

Copy and Past the following into notepad and revise the “yourdomain” fields and Save the file as c:\PassSync.PS1

Import-Module ADSync

$adConnector  = "yourdomain.local"

$aadConnector = "YourDomain.onmicrosoft.com - AAD"

$c = Get-ADSyncConnector -Name $adConnector

$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter "Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null

$p.Value = 1

$c.GlobalParameters.Remove($p.Name)

$c.GlobalParameters.Add($p)

$c = Add-ADSyncConnector -Connector $c

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $false

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $true

Open Powershell as Administrator

Run the following:

Connect-MSOLservice

clip_image001

Then either run the PassSync.PS1:

clip_image002

or cut and paste the contents of the script with your revisions into the powershell window and press enter:

clip_image003

You can confirm the password sync details using Event Viewer Application Viewer Event ID’s 657 and 656:

clip_image005

Wednesday, July 1, 2015

Veeam Backup and Replication on Hyper-V backup failure “user-mapped section open” ‘32768,

Problem: Processing configuration Error: Job failed (''_replica' failed to remove resources. (Virtual machine ID 2A4925C2CD25) The Virtual Machines configuration -2A4925C2CD25 at 'E:\HyperV\Replicas\a4a4fe50e973' is no longer accessible: The requested operation cannot be performed on a file with a user-mapped section open. (0x800704C8).'). Error code: '32768'.

Solution: Temporarily disable your Anti-Virus and retest the replication. Add Anti-Virus exclusions for Veeam and the Hyper-V Configuration file and virtual disk locations and retest.

Tuesday, June 30, 2015

Windows Management Framework 4.0 missing Powershell 4

Problem: After you install the Windows Management Framework 4.0 which includes the update to Powershell 4. It installs successfully but Powershell 4 is missing?

Solution: You probably did not installed the pre-requisite .net 4.5 http://www.microsoft.com/en-us/download/confirmation.aspx?id=30653 

Install .net 4.5 on 2012 from the built in installer. On Windows 7 or 2008 R2 use the download link above.

Note: 2008 R2 SP1 also is required

Once .net 4.5 is installed then rerun the installer for Windows Management Framework 4.0 http://www.microsoft.com/en-us/download/details.aspx?id=40855

Note: you do not have to uninstall and reinstall the package just rerun it.

Restart the system and confirm the version of Powershell you have running use the following command within powershell:

$PSVersionTable.PSVersion

image

Note: For other version prerequisites see the link below for more details

Credit- http://social.technet.microsoft.com/wiki/contents/articles/21016.how-to-install-windows-powershell-4-0.aspx

Thursday, June 25, 2015

Office 365 Installing Office 365 to your RDP Servers

Warning: Uninstall all previous versions of office, that includes 2013 and 365 demos before proceeding
Users must be admins on their systems temporarily for the GPO to work.

Create a shared folder on your central server for example \\SRV-UTIL01\OfficeDeploy\

Download the Office Deployment Tool and extract to \\SRV-UTIL01\OfficeDeploy\

http://www.microsoft.com/en-us/download/details.aspx?id=36778

Create 2 XML files with the options

The first is Download.XML which sets your path, 32 or 64 bit, and is used for the download process:

<Configuration>
<Add SourcePath="\\SRV-UTIL01\OfficeDeploy\" OfficeClientEdition="64" >
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
</Product>
</Add>
</Configuration>

The second is RDPConfiguration.xml used to deploy Office 365 ProPlus package
Note: The example that is included with the Office Deployment Tool might as well be blank since it is rem’d out with the <!— and --!> Here is what it should look like when ready to use:

<Configuration>
<Add SourcePath="\\SRV-FS01\OfficeDeploy\" OfficeClientEdition="64" >
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
</Product>
</Add>
<Updates Enabled="TRUE" UpdatePath="\\SRV-FS01\OfficeDeploy\" />
<Display Level="None" AcceptEULA="True" />
<Property Name="SharedComputerLicensing" Value="1" />
<Logging Path="%temp%" />
</Configuration>

Now to create your local copy of the media run the following command:
Setup.exe /Download Download.xml

Note: when you run the above command above it will create \\SRV-UTIL01\OfficeDeploy\Office\Data\Version\ and under that folder will have the large stream.x32 or .x64 files. This runs in a plain cmd line window with no output on status. So be patient as it will be downloading approx. 2GB of data or more.

While that is downloading you can modify or create your deployment script and GPO

For example RDPOfficePush.bat as shown below:

RDPOfficePush.bat

_______________________________________________________________

echo off

Rem Created by Kevin Oppihle http://Koppihle3.blogspot.com
If EXIST "C:\Program Files\Microsoft Office 15\ClientX64\officeclicktorun.exe" goto 365Complete else goto :365Needed
:365Needed
Echo Installing Office 365 >c:\365.txt
\\SRV-Util01\OfficeDeploy\Setup.exe /configure \\SRV-Util01\officedeploy\RDPconfiguration.xml >>c:\365.txt
:365Complete
Echo Office 365 Installed >c:\365.txt

Exit

________________________________________________________________

The batch file above first confirms if office is already installed. If it is then if you open the txt file c:\365.txt it will say “Office 365 installed”. However if office is not installed it will use the deployment path outlined in the batch file to run the installation. While the installer is running the 365.txt file will say “installing Office 365” when the installation is completed the 365.txt file will change to “Office 365 Installed”. It is set to run minimized so to verify when it is completed reference the 365.txt file. The installation time depends on the network and PC speed but expect an average of 10 minutes. The office icons appear before the installer is completed. If you open an office application before the completion of the installer it will slow the process as it may download from online.

Note: this will install once and activate for each Office 365 user as they log on. So they must have an active Office 365 account. The installation may take a few minutes so please be patient.

Domain Migration SubinACL /Migratetodomain How To:

Caution: DO NOT run this on Domain Controller C:\ and only run on roaming profiles folders, or my docs shares day of migration to avoid ownership change issues.

Confirm Domain trust is in place and users and groups have been migrated

Test ping of olddomain.org from new domain
Test ping of newdomain.org from olddomain

Add newdomain.org domain controller host records to olddomain.org including reverse DNS records

Confirm the user running the app is a domain admin in BOTH domains

Download SubinACL here:

http://www.microsoft.com/en-us/download/details.aspx?id=23510

/Migratetodomain- command will add the permissions of the new user to the old files and folders for example if jimbob@olddomain.org was migrated to the new domain jimbob@newdomain.org and you run the command below any file or folder in that path that has jimbob@olddomain.org will add Jimbob@newdomain.org with the exact same permissions. This is a safer way to migrate by keeping the old and new permissions intact while allowing you time to move the data and users. You can clean up the olddomain permissions after the migration.

To run a pretest from admin command prompt use /testmode command as shown in example below:

Subinacl /outputlog=subinacle_CTest.log /Subdirectories C:\Printe~1\*.* /migratetodomain=olddomain.org=newdomain.org /testmode

To run actual permissions additions to the subdirectories from admin command prompt see example below:

Subinacl /outputlog=subinacle_CPrint.log /Subdirectories C:\Printe~1\*.* / migratetodomain=olddomain.org=newdomain.org

Note: the directory name is c:\printe~1 instead of c:\printer drivers, if working with any path spaces in root commands use 8 character short name in command line.

Note: for root directory permissions you may have to run the script a second time as shown below without the “*.*” for it to add permissions to itself as well

To run actual permissions additions to the directories from admin command prompt see example below:

Subinacl /outputlog=subinacle_CPrintroot.log /Subdirectories C:\Printe~1 / migratetodomain=olddomain.org=newdomain.org

Note: Please be sure to change the output log filename with each run so you have a historical log to reference as I did in the examples above

Real world: “Error when checking arguments- path” is a vague error that makes you think the problem is the path but it is likely a problem with your old and new domain settings.

In my last case I was changing from a test lab domain similar to KOppihle3.local to KOppihle3.com My trust was working fine. When I would ping they resolved, however I was getting the “error when checking arguments” when I would run the following command:

Subinacl /outputlog=subinacle_CTest.log /Subdirectories C:\Printe~1\*.* /migratetodomain=koppihle3.local=koppihle3.com /testmode

The fix was to use the (pre-Windows 2000) netbios Domain name of the 2 Domains instead as shown below:

Subinacl /outputlog=subinacle_CTest.log /Subdirectories C:\Printe~1\*.* /migratetodomain=koppihle3 =ko /testmode

The rest of the story: Initially I quickly spun up a new test lab domain Koppihle3.com and clicked a little too fast without thinking. When I had the new domain up and tried to create the trust from Koppihle3.local to Koppihle3.com it failed because I used the same netbios domain name of Koppihle3 for both domains. I quickly reloaded my “new” test domain and gave it the netbios name KO with the old still using koppihle3 and I was able to create the trust. Then I worked through the scenario above.

Office 365 – Volume License Activation Steps

Log onto Microsoft Volume License site:

https://www.microsoft.com/Licensing/servicecenter/default.aspx

At the top of Home select “View Online Service Activations” as shown below

clip_image001

Select the license and click Manage Activations as shown below:

clip_image003

It is assumed you already have 365 admin account setup so select “I have and account for my organization to use” as shown below:

clip_image004

Enter in your 365 Admin account credentials and Sign in:

clip_image006

Select which licenses you wish to activate and select Start Activation.

clip_image008

Note: You do not have to active them at the same time as in the case above they waited 2 months to activate the E3’s but immediately activated the E4’s.

The License Key will be displayed. Select Next:

clip_image009

Final Confirmation! And Activate!:

clip_image010

Confirm Activation in your 365 console under Billing and Subscriptions :

clip_image012

Trend Micro – WFBS SaaS MSP Adding a Client Administrator

Log onto the Licensing Management Platform using the following link:

https://licensingplatform.trendmicro.com/xLP/EndUserMng/EndUser/Landing?T=4DBC6EAD

clip_image002

Top Right Select “Trend Micro Remote Manager”:

clip_image003

Left side “Customers”:

clip_image005

Select that specific Customer and “WFBS-SVC_WFBS_SaaS_MSP”

clip_image007

Select Administration> Manage Co-Administrators:

clip_image009

Add administrator:

clip_image010

Enter in the username, information, submit and it will send out an email for their approval and allow them to set their own password:

clip_image012

Note: They are a FULL administrator at this point so be very cautious and warn them of potential dangers/impact to making any changes.

Office 365 Powershell access with username change example

$UserCredential = Get-Credential

Enter in 365 admin and credentials when prompted:

image

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic –AllowRedirection

Import-PSSession $Session
image

Connect-msolservice

Enter in 365 admin and credentials when prompted:

image

Username change:

Set-MsolUserPrincipalName -newuserprincipalname newname@yourdomain.com -userprincipalname oldname@yourdomain.com

Credit- https://technet.microsoft.com/en-us/library/hh974317.aspx

Exporting Email from Exchange 2010 to PST – About everything that could go wrong

So a client had an old SBS 2011 server that was out of service with Exchange 2010 on it. They have been running Office 365 for about 9 months and did a clean cutover no migration, since most of the data was, as they put it “old junk”. However they wanted a copy of that “old junk” before that server is taken to the recycle center just in case. Which is always a good idea and sounds simple enough. Since it is exchange 2010 you don’t have to use exmerge or some other older tool you can use powershell commands that export each mailbox to its own big .PST to a drive share that will be copied to a copy external hard drives or tapes and put on a shelf and be forgotten about till some needs a drive or tape.

So I start out trying to run the basic command to give myself permissions:

New-Managementroleassignment –Role “Mailbox Import Export” –User “Administrator”

Command does not exist… (Quick Research and I need to add Exchange Service Pack 1)

Install SP1 and run the command above again and it completes but then the sub commands fail.

$Export = Get-Mailbox

Note: Once you run the first permissions command above you may have to close and reopen Powershell or even log off and on of the system.

I create a Shared folder for the PST exports and ran the following with my share path:

$Export|%{$_|New-MailboxExportRequest -FilePath "file:\\servername\pst\$($_.alias).pst"}

then I receive unable to access path?

So I try every possible path. And went back to basics and browsed to the path. Sure enough I could see the folder in explorer but when I clicked on it would fail with path not found!? So I double check permissions on the share and then browse to another old share and the same error. At this point I realize there is probably a name resolution issue. From a quick ping I saw it was still searching for the old IP. I quickly found there was a host file using the old IP so I removed that. I was then able to Ping correctly and browse to the shares.

I would try this or that but it was just an endless trail of errors for what should be a simple three or 4 lines of PS and done. The errors included:

Remote Permanent Exception ‘Fully Qualified Error, Transient Service Error, Unable to access Mailbox.

Attempted fixes included: Confirmed mailboxes were not disabled, Enable Exchange Replication Services, Add Exchange Trusted Subsystem group to share

I knew all my permissions and settings were correct. So we determined it had to still be name resolution so we went deeper into SBS. Since it was a DC it still had references to the old static IP from a different NIC. Now it is using DHCP. So I set the IP as static to what it was now receiving from the DHCP server and excluded it on the scope for now till this project is done. I then added DNS entries for its new IP address in it’s local DNS, confirmed the network bindings were in order since it is using a different NIC. Flushed the local DNS cache and ran clean nslookups. We then restarted the server. Logged back on and then everything worked as it should have from the beginning. Here are the commands in order and steps if your environment is clean and running Exchange SP1:

· Create a network share for the PST files and share with admin performing this process and Exchange Trusted Subsystem.
· New-Managementroleassignment –Role “Mailbox Import Export” –User “Administrator”
· $Export = Get-Mailbox
· $Export|%{$_|New-MailboxExportRequest -FilePath "file:\\servername\pst\$($_.alias).pst"}

Monday, March 9, 2015

SBS2011 Limiting Exchange 2010 Store Memory

Problem: Exchange 2010 Store is using too much memory making response times slow for other services. The problem may be related to your Exchange 2010 Cache Sizes. See the chart below:

Default mailbox database cache sizes:

Server physical memory (RAM)

Database cache size: (Mailbox role only)

Database cache size: Multiple-role (Mailbox + Hub Transport)

2GB

512 MB

Not supported

4GB

1 GB

Not supported

8GB

3.6 GB

2 GB

16GB

10.4 GB

8 GB

24GB

17.6 GB

14 GB

32GB

24.4 GB

20 GB

48GB

39.2 GB

32 GB

64GB

53.6 GB

44 GB

96GB

82.4 GB

68 GB

128GB

111.2 GB

92 GB

Solution: To revise the size limits you need to open ADSIedit, right click on ADSIEdit and select “Connect to…” as shown below:

clip_image002

In Connection Settings > select a well know Naming context “Configuration” and “OK” as shown below:

clip_image004

Now we need to drill down to the proper CN=Information Store

Configuration>Configuration>Services>Microsoft Exchange> First Organization> Administrative Groups> Exchange Administrative Group> Servers> Servername> InformationStore as shown below:

clip_image006

Right click on CN=Information store and select properties, Scroll down to “msExchESEParamCacheSizeMax”, select and click Edit as shown below:

clip_image008

Now input the memory limit of your choice using the calculation guide below:

clip_image010

Exchange 2010 on SBS2011 uses 32KB pages so to calculate the number to input:

4GB=4194304 KB /32 = 131072
5GB=5242880 KB /32 = 163840
6GB=6297456 KB /32 = 196608
7GB=7340032 KB /32 = 229376
8GB=8388608 KB /32 = 262144

clip_image012

In this instance I am going with 8GB. You can go higher by continuing the table above to come up with your Value calculation.

Then stop and restart your Exchange Store and see the immediate results.

Note: The lower the setting the more it will impact your Exchange environment so you may have to do some up and down adjustments to make it work best for your situation.

Credit:
Andy Cook
Michel de Rooij
http://eightwone.com/2010/03/25/limiting-exchange-2010-database-cache/
https://technet.microsoft.com/en-us/library/ee832793.aspx

Thursday, March 5, 2015

Office 365 Deployment Tool Office Download fails “Could not Install”

Problem: you run the setup.exe /download download.xml and fails immediately with “Couldn’t install”

image

image

You make sure all the settings are correct (see other blogs) and find nothing wrong

Solution: Change drives and run it as an administrator again.

For example above i am in the F:\OfficeDeploy directory which is the same directory I have the download.xml directing the download to. If i Change to the c: and run the same command again it works

image

The Office Data folder was created and updated as shown below:

image

Trend Worry Free Console cannot open ieframe.dll page displays

Problem: You install Trend Worry Free and cannot access the console. When prompted with “There is a problem with this website’s security certificate” warning and you click continue as shown below:

image 

You receive the following error “this page can’t be displayed” res://ieframe.dll/:

image

Solution: Add res://ieframe.dll/ and your Trend Worry Free Site to local intranet.

Internet Options> Security> Local intranet>Sites:

image

Advanced:

image

Add> res://ieframe.dll/ and your Trend Console site such as https://srv-util01.corp.example.com:4343

uncheck require https:// and close

image

Restart your browser and test.

Credit References:
Giampiero Censori

Thursday, February 19, 2015

Office 365 Domain install with a local share via Script and/or GPO

Warning: Uninstall all previous versions of office, that includes 2013 and 365 demos before proceeding
Users must be admins on their systems temporarily for the GPO to work.

Create a shared folder on your central server for example \\SRV-UTIL01\OfficeDeploy\

Download the Office Deployment Tool and extract to \\SRV-UTIL01\OfficeDeploy\

http://www.microsoft.com/en-us/download/details.aspx?id=36778

Create 2 XML files with the options

The first is Download.XML which sets your path, 32 or 64 bit, and is used for the download process:

<Configuration>
<Add SourcePath="\\SRV-UTIL01\OfficeDeploy\" OfficeClientEdition="64" >
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
</Product>
</Add>
</Configuration>

The second is Configuration.xml used to deploy Office 365 ProPlus package

Note: The example that is included with the Office Deployment Tool might as well be blank since it is rem’d out with the <!— and --!> Here is what it should look like when ready to use:

Note: Version is optional however it assures your system will use the media version you have in that path and not grab a newer version online.

<Configuration>
<Add SourcePath="\\SRV-UTIL01\OfficeDeploy\" Version="15.0.4649.1001" OfficeClientEdition="64" >
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
</Product>
</Add>
<Updates Enabled="TRUE" UpdatePath="\\SRV-UTIL01\OfficeDeploy\" />
<Display Level="None" AcceptEULA="TRUE" />
<Logging Path="\\SRV-UTIL\OfficeDeploy\Logfiles\" />
<Property Name="AUTOACTIVATE" Value="1" />
</Configuration>

Now to create your local copy of the media run the following command:
Setup.exe /Download Download.xml

Note: when you run the above command above it will create \\SRV-UTIL01\OfficeDeploy\Office\Data\Version\ and under that folder will have the large stream.x32 or .x64 files. This runs in a plain cmd line window with no output on status. So be patient as it will be downloading approx. 2GB of data or more.

While that is downloading you can modify or create your deployment script and GPO

For example OfficePush.bat as shown below:

OfficePush.bat

echo off
Rem Created by Kevin Oppihle http://Koppihle3.blogspot.com
If EXIST "C:\Program Files\Microsoft Office 15\ClientX64\officeclicktorun.exe" goto 365Complete else goto :365Needed
:365Needed
Echo Installing Office 365 >c:\365.txt
\\SRV-Util01\OfficeDeploy\Setup.exe /configure \\SRV-Util01\officedeploy\configuration.xml >>c:\365.txt
:365Complete
Echo Office 365 Installed >c:\365.txt
Exit

The batch file above first confirms if office is already installed. If it is then if you open the txt file c:\365.txt it will say “Office 365 installed”. However if office is not installed it will use the deployment path outlined in the batch file to run the installation. While the installer is running the 365.txt file will say “installing Office 365” when the installation is completed the 365.txt file will change to “Office 365 Installed”. It is set to run minimized so to verify when it is completed reference the 365.txt file. The installation time depends on the network and PC speed but expect an average of 10 minutes. The office icons appear before the installer is completed. If you open an office application before the completion of the installer it will slow the process as it may download from online.

Now you need to copy the batch file to your sysvol scripts and assign the batch file to be a logon script of the users.

Note: this will check and install as necessary every time the user logs on so once your deployment is finished unassign the GPO.

Happy Office 365 Deployment!

Wednesday, February 18, 2015

AD how to reset the DSRM password

Log onto the Server as an Administrator

1. open Ntdsutil
2. set dsrm password.
3. reset password on server null.
4. Type the new password when you are prompted and enter
5. Reenter the new password and enter
6. Q to quit
7. Document the change

Powershell - Adding email address and other informational fields to AD in bulk

You setup your new domain imported or added user then realize you left out a field such as mail details. Since all users are different you can’t do a bulk select all and edit you have to set each one individually or via a .csv file and script. Here is a working example:

note: If your “user logon name” does not match your “user logon name (Pre-Windows 2000)” it will fail on those users.

Create an excel file with the following fields and export to a csv called c:\admailfield.csv

name mail
kevin.oppihle kevin.oppihle@domainname.com

Create a .txt file and input the following

$users=import-csv C:\Source\admailfield.csv
foreach($user in $users){
$u = Get-ADUser $user.name -Properties mail
$u.mail = $user.mail 
Set-ADUser -instance $u
}

Save the file as admailfiled.ps1

Open powershell as an administrator on you local AD server and run

 ./admailfield.ps1

You can then use AD users and computers to confirm the changes were added to AD

Credit References:

DuRand Bryant

Office 365 DirSync users getting domainname.onmicrosoft.com addresses as default

You setup Office 365 DirSync and the default domain for the users is domainname.onmicrosoft.com instead of your default defined domain in Office 365. It will not allow even the Office 365 administrator change the email addresses of individual users from the Office 365 console. The reason is with AD synchronization enabled by default it uses the proxy address field of the user sent from AD. If that is blank in AD it will use domainname.onmicrosoft.com.

You can either use ADSIedit to modify the proxy address fields individually for each user or you can use a powershell script and csv file such as the one below to do so in bulk.

Word of warning it will overwrite any existing proxyaddresses not just SMTP: (primary) it will also remove smtp: (aliases) if you run it as is.

Additionally if your “user logon name” does not match your “user logon name (Pre-Windows 2000)” it will fail on those.

Create an excel file with the following fields and export to a csv called c:\mailboxlist.csv

name ProxyAddress
kevin.oppihle SMTP:kevin.oppihle@domainname.com

Create a .txt file and input the following

$users=import-csv C:\mailboxlist.csv
foreach($user in $users){
$u = Get-ADUser $user.name -Properties mail,department,ProxyAddresses
$u.ProxyAddresses = $user.ProxyAddress 
Set-ADUser -instance $u
}

Save the file as proxyemail.ps1

Open powershell as an administrator on you local AD server and run

 ./proxyemail.ps1

You can then use ADSIedit to confirm the proxy addresses were assigned to the users.

With the next DirSync process the updates should push to Office 365

Credit References:

Daryl Hunter, DuRand Bryant

Office 365 using DirSync users cannot change passwords in Office 365

If you do directory sync from AD to Office 365 users will not be able to change their passwords on the Office 365 portal. Since the AD sync is a one way process the password changes do not come back into AD locally. Thus by default the Office 365 Portal will not allow users to change their passwords as they will just be overwritten by the local AD.

The problem this creates is sometimes you have a mix of users some local and some that may not have local domain access to change their passwords. The following is a work around using OU exclusion from DirSync.

First we need to put the users in a separate OU such as “Webmail” then we will exclude that OU from DirSync. That will allow them to change from “Directory Synced” to “Cloud”. Which you can confirm in the Office 365 Admin Console. Here are the steps:

Caution: Seasoned Domain Admins Only this is Active Directory and email flow will be impacted for users as they are changed

“you break it you bought it…”

Copy Shortcut to desktop

C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe
clip_image001

Open and select Management Agents and The Active Directory Connection:

clip_image003

Right Click and Select Properties:

clip_image005

Select Configure Directory Partitions and Containers:

clip_image006

You will be prompted for credentials enter in your LOCAL ADSync Username and Password

clip_image008

Browse and Exclude the OU:
clip_image009

Select “OK” “OK”

You can now force the DirSync process.
Open up PowerShell as Administrator and Run the following command to initiate a sync:

Import-Module DirSync
Start-OnlineCoexistenceSync -fullsync

clip_image010

Select the Operations tab to view status:
clip_image012

Note Deletions in the bottom right:
clip_image013

Note: force the DirSync process 2 to 3 times to make sure all settings synchronize

Log onto Office365 portal> Deleted Users> Select Users> Restore Users:

clip_image015

clip_image017

clip_image019

The users should now be able to change their passwords from the webmail interface. If not use the admin console to force a password reset per user to purge out any AD password settings.

In my testing since I performed this process after hours and quickly restored the accounts little to no email was kicked back as “recipient does not exist” additionally the end users did not notice any impact to their email as it is in a limbo state not yet truly “deleted”

I would recommend you use a test account or 2 to make sure you have the process down before doing any mass moves.