Office 365 does not have the ability online to have a password to never expire. The way to have a password to never expire is through PowerShell. After connecting to Azure in Powershell, type Set-Msol User -UserPrincipalName User ID -PasswordNeverExpires $true to make the password out one user never expire. If you want to set this for every user in the organization, use the command Get-msol user | Set-msol user -PasswordNeverExpires $true.
Upgrading a Windows Server Failover Cluster to the next version of Windows Server is not one of the easies processes compared to other server roles. When I was ready to move my cluster to 2012 I looked online for the best resource that I could find to help with the transition. During my search I found this MSDN article that is as close to a step-by-step that I could find. There are two different ways to move from 2008 R2 to 2012: Windows Server 2012 Failover Cluster Migration Wizard or System Center 2012 Virtual Machine Manager with Service Pack 1. I used the Migration Wizard. In order to use the Migration Wizard, you need to create a new cluster. I had six nodes running my cluster, to create the new cluster I evicted half and created a new 2012 cluster with them. I then connected my SAN via iSCSI to my new cluster while connected to my old cluster. Next I ran the migration wizard to copy the configuration over to the new cluster. After this step, I took the Virtual Machines and the shared storage offline (in that order) in Failover Cluster Management in the 2008 R2 cluster. As soon as I did this the storage then appeared in the 2012 management window and I put them online. Now I am running on Windows Server 2012.
When you decide to make the move to Windows Server 2012 for you Active Directory Federation Services server, there are a few things to keep in mind. First is the migration process for ADFS on Windows Server 2008 R2 to Windows Server 2012. The second one is if you as an organization are using ADFS with Office 365. If you are using Office 365, then the relying trust can not be added back manually like the first document says. Office 365 automatically created this when running the federation command in PowerShell when you originally federated the domain to Office 365. You would need to repair the relying trust with PowerShell. Follow these instructions from Microsoft.
Microsoft DirectAccess is a new type of remote connectivity to an organization’s intranet. DirectAccess use the local DNS servers for regular internet traffic but direct all traffic amid at resources in the organizations intranet to the public facing DirectAccess server. When DirectAccess is set up, a Group Policy Object is made to configure the client computers to use the DirectAccess server for DNS anytime they are not connected to the intranet. The Name Resolution Policy Table (NRPT) contains the settings used by the DNS client on the computer that determines what happens to DNS queries. If DirectAccess is not set up correctly, then the status DirectAccess is shown as “Connecting”. When DirectAccess is in this state it can not contact anything on the corporate domain because the NRPT is telling the DNS queries to go through the DirectAccess connection but the client can’t contact the DirectAccess Server. This can also be a problem if you need to update the Group Policy to remove the DirectAccess settings.
To force the computer not to use DirectAccess settings:
- Open the Microsoft Management Console
- Add the Group Policy Object Editor for the Local Computer
- Navigate to Computer Configuration/Windows Settings/Name Resolution Policy
- Choose “Advanced Global Policy Settings”
- Check the box for “Configure roaming options” under “Network Location Dependency”
- Choose the “Never use DirectAccess settings in the NRPT”
- Choose “Ok” to close and then “Apply” to apply settings
- Close out of MMC
- Turn the Surface on
- Attach the Touch or Type Keyboard to the Surface
- Hold down the Shift Key at the Login Screen
- Click on the Power icon
- Click on Restart
- Click on Troubleshoot
- Choose either Reset or Refresh
The other day I needed to change the default email address on my Office 365 mailbox. I was hoping it would be as easy as logging in to the Admin Page and selecting the address, but we sync our local Active Directory to Office 365. After searching I found I needed to edit the local attributes of an account in Active Directory Administration Center to change the default email address. The attribute that controls e-mail address assigned to a user is the proxyaddress field. This attribute lists all email addresses that are attached to a user’s mailbox. The address that is listed with the SMTP: before it is the primary address. You can add more addresses by starting it off with smtp:.
Here is a Microsoft Support Article on this topic that is helpful. Step Number 4 is what is described above.
If you use Office 365 or another Microsoft Online Service, you may be using Microsoft Windows Azure Active Directory Sync Tool. This tool allows your local on-premise Active Directory to be synced with the Windows Azure Active Directory (Azure AD). The Sync Tool syncs local changes to the attributes of users, groups, and mail contacts to the cloud (does not sync cloud to local) every two hours. You can speed up the process by forcing the sync. Follow these steps to force a sync:
1. Log on to the server that has the Windows Azure Active Directory Sync Tool installed using a member of the local admin group
2. Use File Explorer to navigate to C:Program FilesMicrosoft Online Directory Sync
3. Click on DirSyncConfigShell.psc1
4. Once the Powershell window opens, type Start-OnlineCoexistenceSync
5. Hit the Enter key and the sync should have started