Hybrid 365 User creation

Recently a friend of mine was doing a deployment of Office 365 in a hybrid environment with Exchange 2013.

There was a CSV file with the required fields, and he asked me to help him create a script to create the users.

I did him one better, and also enabled the mailboxes on 365 for him.

$Users = Import-Csv -Path "C:\Users.csv"
$OU = read.host "What OU would you like the users created in?"       
$domain = read.host "What is your domain?"
$Password = read.host "What password would you like to set all accounts to?"     
foreach ($User in $Users)            
{            
    $Displayname = $User.Firstname + " " + $User.Lastname            
    $UserFirstname = $User.Firstname            
    $UserLastname = $User.Lastname            
    $SAM = $User.Username          
    $UPN = $User.Firstname + "." + $User.Lastname + "@" + $domain
    $Mobile = $User.Mobile
    $Home = $User.PersonalEmail
    New-ADUser -Name "$Displayname" -DisplayName "$Displayname" -SamAccountName $SAM -UserPrincipalName $UPN -GivenName "$UserFirstname" -Surname "$UserLastname" -AccountPassword (ConvertTo-SecureString $Password -AsPlainText -Force) -Enabled $true -Path "$OU" -ChangePasswordAtLogon $false –PasswordNeverExpires $true -MobilePhone $Mobile -HomePhone $Home
    $RemoteRouting = "smtp:" + $UPN
    Enabled-RemoteMailbox $SAM -RemoteRoutingAddress $RemoteRouting
}

A quick run through.
The script will prompt the OU path where you want to create the users, the domain and the password you want to use.

It then creates the account, with the fields populated by the CSV file.
Those fields are Firstname, Lastname, Username, Mobile, PersonalEmail
Once the account is created, it will then create the mailbox on 365.

All that's left to do is assign the licenses.



Quick sidenote: while running through the script in the lab worked well without problem, in production we could not run the script more than once without requiring a restart of EMS.

Event ID 15021 HttpEvent

I received a call to advise that none of my clients Outlook clients could connect to Outlook.

After ruling out the usual suspects, I dug a little deeper, and found a number of these events in the System event logs on the mail server.

This was also 

The fix was pretty straight forward.
On the mail server, run CMD as Administrator, and run the following commands.

netsh http show sslcert

Copy down the certhash and appid from 0.0.0.0:443

netsh http delete sslcert ipport=0.0.0.0:444

netsh http add sslcert ipport=0.0.0.0:444 certhash=<insert your copy here without the brackets> appid="Insert your copy here, including the " and {}."

Once all that is done, everything should be working perfectly fine again.

Server 2012 R2 drive Access Denied

Recently we took over a client, whose entire network structure was just....abysmal. While doing an audit of the system, I discovered that my Domain Admin account had no access to the data drive on the file server.

I could get to the share without a problem, but could not access the drive through the server directly.

I took stock of who had access to what folders in the shares, and took control of the folder. Some hours later, after it had finished, I had full access to the security tab again, but I still could not access the drive normally.

Ultimately, the resolution was to the local server group "Users" with default access, as seen below.

Best practice is a thing for a reason. Never change the permissions on the drive - only on a folder.

Exchange 2007 Autodiscover / Office 365 Staged Migration.

Recently, I was assisting a friend with getting Autodiscover workign for Exchange 2007, so he could Migrate them to Office 365, utlising the Staged Migration process.

He was receiving the following error message.






















Autodiscover was not configured for external use. So we had to configure that, by using the following commands. $env:computername is a system variable, which calls the computer name you're running on the command on. Feel free to change this to the CAS server name.

I always use autodiscover A record for this, but this requires you to have it on the certificate as a SAN or use a wildcard cert. Feel free to change this to whatever is on the certificate you're using. If you're using a self signed certificate....replace it with one from a recognized CA.

Set-AutodsicoverVirtualDirectory -Identity "$env:computername\Autodiscover (Default Web Site)" -ExternalURL "https://autodiscover.domain.com/Autodiscover/Autodiscover.xml"

Set-ActiveSyncVirtualDirectory -Identity "$env:computername\Microsoft-Server-ActiveSync" -ExternalURL "https://autodiscover.domain.com/Microsoft-Server-ActiveSync" 

We also set up a CNAME for autodiscover address to go to the A record for the server externally.
Once we had completed this, we ran the Exchange Connectivity Test, which returned the following result.

Further troubleshooting resulted in the following webpage, when attempting to get to the address specified in the commands above.

Heading into IIS Manager, we headed straight for the Authentication for the Autodiscover web page.

We noticed that Windows Authentication was set to Disabled. Setting that to Enabled, we were still out of luck.

We then double checked the Microsoft-Server-ActiveSync Authentication, and Windows Authentication was Disabled there, too.

Changing that we managed to get some success!

This resulted in a successful Autodiscover test.

However, \when attempting to run through the Migration Endpoint Wizard, it returned the following error.

Everything was correctly configured.

Ultimately the last piece of the puzzle was IPv6.

It was disabled on the host, but still communicating, and taking priority for autodiscover.

Setting a couple of static addresses in the HOSTS file, allowed us to connect instantly.

RD Gateway Port Change

I recently had to set up a Remote Desktop Services deployment at a client who only had a single external IP, and utilising port 443 for their on premise Exchange server, for OWA.

Once the deployment process had finished, I launched RD Gateway Manager from the Server Manager. Went to the properties of the server, and selected Transport Settings. Changed the default port to whatever, I'm using 8443 in this example.

Once changed, I loaded IIS and checked the Default Web Site to ensure that the port had been correctly bound to RDWeb, which it had automatically.

Quick test ensured internal and remote access to RDWeb via the new port.

Testing any of the Published Apps, or the Remote Desktop, failed with the following.

When editing the .RDP icons, I found that there was no port.

 There are 2 methods of fixing this. One is in the registry, and the other is the correct way of doing it, which is using Powershell.
Run Powershell as Administrator, and use the following command "Set-RDSessionCollectionConfiguration -CollectionName "CollectionName" -CustomRdpProperty "gatwayhostname:s:<YOUR HOST NAME>:<PORT NUMBER>"

Confirm this has taken effect by using Get-RDSessionCollectionConfiguration.

Once you've run that, refresh your RDWeb page (if it's still open) and download the .RDP file again, and you will find upon editing, that it will have the port under the RD Gateway Server settings.

Security Group Membership Export

A while back, I posted about email address auditing, and a way to export all members of distributioun groups from powershell. I found this incredibly useful, and use it quite often. I've always talked to my colleagues about looking into a similar script for

I've just created a nice little script that deals with that in a manner that I think is appropriate.

Import-Module ActiveDirectory
$ou = Read-Host -Prompt 'Specify Organizational Unit here'
Get-ADGroup -filter {GroupCategory -eq "Security"} -SearchBase $ou |  ForEach-Object {
$group = $_.SamAccountName
$saveto = $("C:\temp\" + $_.Name + ".csv")
Get-ADGroupMember -identity $group -recursive | select Name | Export-Csv $saveto
}

I've specify the OU where my custom security groups are, otherwise I would be exporting groups like Domain Computers.

This creates a CSV file for each individual security group, with the same name as the security group.

Hope this helps someone who is looking for the same solution.

AD / SYSVOL Version Mismatch

I recently had a call from a client, advising they were unable to RDP to a server.
After basic troubleshooting, I discovered that the Windows Firewall was blocking port 3389 from all sources, which was set by server.

I checked the Group Policy in question, and confirmed that Allow inbound Remote Desktop exceptions was configured.




I then confirmed that I could RDP to other servers in the same security groups and OUs.
I ran GPRESULT /R GPreport.html, which returned the following results.

Labtech is in use on this site, and the firewall rules are set from within the Default Domain Policy.

A quick look around advised me that this error for Windows 8/Server 2012 had this hotfix available. Windows 8.1/Server 2012 R2 has this issue fixed with this update

After installing this hotfix, and rebooting the server, I had one rather happy client.