Network Diagnostics Tool

MXToolbox - http://mxtoolbox.com

End-To-End setup for Office 365 - All steps

http://www.slideshare.net/technetbelux/office-365-planning-and-automating-for-hybrid-identity-scenarios-in-the-cloud-a-geeks-guide-to-dir-sync-and-adfs-with-tools-scripts-and-deployment-hydration

Exchange Server Online - Configuration

Use Windows PowerShell to connect to Exchange Online - Link
http://technet.microsoft.com/en-us/exchangelabshelp/cc546278

Install and Configure Windows PowerShell for MS Exchange Online - Link
http://technet.microsoft.com/en-us/exchangelabshelp/cc952756

Changing Users Primary email address - Link
http://technet.microsoft.com/en-us/exchangelabshelp/dd251224

Email sub-domain issue - Link
http://community.office365.com/en-us/f/158/t/44701.aspx

API to get token using WIF

Copy-pasted from blog - http://blogs.southworks.net/mwoloski/2009/07/17/getting-a-token-from-adfs-ex-geneva-server-using-wcf/

I’ve been doing some tests to get a token from ADFS (Geneva Server) using Windows Identity Foundation  WSTrustClient. In this case we are using the UserNameMixed endpoint that expects a WS-Security UsernameToken (notice the MessageCredentialType.UserName).

internal static ClaimsIdentityCollection RequestTokenWithUsernameMixed()
{
    var binding = new WS2007HttpBinding(SecurityMode.TransportWithMessageCredential, false);
    binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
    binding.Security.Message.EstablishSecurityContext = false;

    var credentials = new ClientCredentials();
    credentials.UserName.UserName = "Mary";
    credentials.UserName.Password = "Passw0rd!";
    var endpoint = "https://mygenevaserver/Trust/13/UsernameMixed";
    var client = new WSTrustClient(binding, new EndpointAddress(new Uri(endpoint)), TrustVersion.WSTrust13, credentials);

    var request = new RequestSecurityToken();
    request.RequestType = "http://schemas.microsoft.com/idfx/requesttype/issue";
    request.AppliesTo = new EndpointAddress("http://localhost/activerp");
    var token = client.Issue(request) as GenericXmlSecurityToken;

    var claims = token.ToClaimsIdentityCollection(TrustVersion.WSTrust13,                   CertificateUtility.GetCertificate(StoreName.My, StoreLocation.LocalMachine,                   "CN=Geneva Signing Certificate - WIN-66EYOLL2BVY"),                   CertificateUtility.GetCertificate(StoreName.My, StoreLocation.LocalMachine,                   "CN=WMSvc-WIN-66EYOLL2BVY"));

    return claims;
}

Here is another one using the WindowsMixed endpoint (notice the MessageCredentialType.Windows and no username and password set)

internal static ClaimsIdentityCollection RequestTokenWithWindowsMixed()
{
    var binding = new WS2007HttpBinding(SecurityMode.TransportWithMessageCredential, false);
    binding.Security.Message.ClientCredentialType = MessageCredentialType.Windows;
    binding.Security.Message.EstablishSecurityContext = false;

    var credentials = new ClientCredentials();
    var endpoint = "https://mygenevaser/Trust/13/WindowsMixed";
    var client = new WSTrustClient(binding, new EndpointAddress(new Uri(endpoint)), TrustVersion.WSTrust13, credentials);

    var request = new RequestSecurityToken();
    request.RequestType = "http://schemas.microsoft.com/idfx/requesttype/issue";
    request.AppliesTo = new EndpointAddress("http://localhost/activerp");
    var token = client.Issue(request) as GenericXmlSecurityToken;

    var claims = token.ToClaimsIdentityCollection(TrustVersion.WSTrust13,                    CertificateUtility.GetCertificate(StoreName.My, StoreLocation.LocalMachine,                    "CN=Geneva Signing Certificate - WIN-66EYOLL2BVY"),                    CertificateUtility.GetCertificate(StoreName.My, StoreLocation.LocalMachine,                   "CN=WMSvc-WIN-66EYOLL2BVY"));

    return claims;
}

You can use this together with the CreateChannelWithIssuedToken extension method

ADFS Sandbox setup

Minimal sandbox ADFS setup for Office 365:
Copy-pasted from the below URL - 
http://www.wapshere.com/missmiis/minimalist-office-365-with-adfs-sandbox

It’s kind of killing my laptop, but I have managed to get my virtual lab environment working with ADFS to an Office 365 trial. I think I’ve probably got the bare minimum config going on here, so for reference, here’s what I had to do.

Ingredients

• A host computer – in my case my Win7 laptop running Oracle VirtualBox,
• An Office 365 trial,
• A real live domain name that is resolvable on the internet and which you (or someone who likes you) has admin access to (this will be necessary for the verification process),
• A SSL certificate for said domain name,
• The following VMs:
• DC + ADFS: Win2008R2, 1024 MB of RAM (I couldn’t get ADFS to install with only 512MB), virtual network and internet access
• DirSync: Win2008x32, 512 MB of RAM, virtual network and internet access
• Workstation: Win7, 512 MB of RAM, virtual network and internet access

Note: there is now a 64 bit version of DirSync so it should be possible to install that on the DC as well.

AD

The name of my virtual AD domain did not match the external domain I had to use for ADFS. This does not matter – just add the external domain as a UPN suffix to AD.
You then also need to make sure any account you want to test with has a UPN of accountname@myrealdomain.com.

Certificate

I was under the impression that I’d need a public cert so Microsoft would trust my ADFS server, so I got a free one month cert from freessl. However I can see now that the cert is only used for internal communication between my ADFS server and my client, so I think now if I’d generated one in my own CA it would have been fine. The only provisio is the name of the cert must match myrealdomain.com.

ADFS

The instructions walk you through a proper setup with NLB and federation proxies. With a laptop lab I did none of this. I just have the one federation server running on my DC. Pretty much all I did was:

1. Installed ADFS – make sure you choose “first server in a farm”,
2. Installed the SSL certificate for myrealdomain.com onto the default IIS website,
3. Ran the ADFS wizard,
4. Ran the powershell cmdlets to add and federate the domain in Office 365 (documentation).

Internet Firewall

Another thing I was mistaken about was thinking the Microsoft Federation gateway would need to talk directly to my ADFS server but actually it doesn’t – the communication is between the client browser and ADFS. I’m not allowing external devices to access Office 365 via my lab, so I don’t need to grant access to my ADFS VM through the network firewall. Which is a relief!

DNS

The domain myrealdomain.com has a real, live ip address on the internet, however in my virtual network I want it to resolve to the internal ip address of my ADFS server. To do this I:

• Created a Primary Zone for myrealdomain.com in my domain’s DNS service,
• Created an A record in the zone pointing to the internal ip address of the ADFS server,
• Set a forwarder to the external DNS server, and
• Made sure all VMs in my virtual network used the virtual DC for DNS, rather than going straight to the external DNS.

DirSync

As I noted above, when I wrote this article there was only 32 bit DirSync. Now we finally have a 64 bit version. It should run on the DC but I haven’t tried it.
DirSync is damn easy to install. Just follow the instructions.

Activate an account

Once you have accounts DirSync’d up to Office 365, with the correct UPN matching the real domain that you federated, you can now activate one or two of them to use as tests.

Test

To test I logged in to my virtual workstation. This has a bridged internet connection in addition to the virtual network connection, and all DNS goes via the virtual DC.
I went to https://portal.microsoftonline.com and entered the user’s UPN. When I clicked the Password box it was greyed out and a link appeared telling me to authenticate against myrealdomain.com. I clicked this link and, after a few URL changes flicked across the address bar, I’m in!

Troubleshooting

The main mistake I made was to install the ADFS server in standalone mode the first time. Login actually worked, but it wasn’t SSO – the user had to re-enter their username and password. Checking the Security log on the DC showed NTLM auth being used.
So I re-ran the ADFS wizard (as the link had dissappeared from the Mnagement console I ran C:\Program Files\Active Directory Federation Services 2.0\FsConfigWizard.exe) and chose server farm. I then re-ran the powershell cmdlet Convert-MsolDomainToFederated.
Everything looked good, but wasn’t. I kept getting “Your organization could not sign you in to this service”. In the event logs I could actually see the user successfully logging in with Kerberos, but at the same time a KDC_ERR_BADOPTION error.
After much troubleshooting and hair-tearing I decided to run the powershell cmdlet Update-MsolFederatedDomain – and it fixed the problem!
As I’d had the foresight to run a Get-MsolFederationProperty both before and after the Update cmdlet I could actually compare and see what changed. The problem was the TokenSigningCertificate – it looks like the Convert cmdlet did not overwrite this so it still had the old thumbprint. After I ran Update the thumbprint changed to the new cert.

Using ADFS to federate your Office 365 domain

Copy-Pasted from the following link:
http://360on365.com/2011/03/04/how-to-federate-your-domain-with-office365/

HOW TO: Federate your domain with #Office365

by martijnbakx85 In the last posts we talked about the enduser experience when using federation. But how do we ‘Administrators’ set it up? Before you start clicking you should remember one very important thing and that is the Active Directory preparation. A lot of companies have their Active Directory domain ending on .local or some variation to that. When you want to federate with #Office 365, your users can’t logon with that domain name. Because domain.local is not resolvable on the internet.
To solve this issue you should give the AD users a User Principle Name (UPN) suffix that matches the domain you want to federate. For example user@fabrikam.com. A best practice is to use the users emailaddress as his/her UPN. Don’t underestimate this step. Depending on your current environment this will be a separate project.
After AD preparation we continue with the creation of a DNS record for the #ADFS2.0 server. In the internal DNS zone of fabrikam.com, create a host record called ‘sts’ which points to your #ADFS2.0 Server.
Now the preparations are done, we are going to install ADFS2.0. In the Server Manager of Windows Server 2008 R2 you also find a version of ADFS, this is however an old version and should not be used in conjunction with #Office365. You can download the correct version here. After downloading the package, run AdfsSetup.exe. After the License agreement page, you’re asked if you want this to be a Federation or Federation Proxy server. The federation server/farm will be installed on the internal network and the proxy server will be placed in the DMZ. So in our situation we choose for the Federation server and proceed with the automatic installation of the following prerequisites:

Before we configure ADFS, we have to create a new domain certificate for ‘sts.fabrikam.com’ and assign it to the default web site on the ADFS server using IIS Manager.
After we’ve done this, it’s time to configure Active Directory Federation Services 2.0. To do this we will follow these steps:
1. Open ADFS 2.0 Management Console
2. In the results pane click on “ADFS 2.0 Federation Server Configuration Wizard”
3. Choose for “Create a new Federation Service”
4. Choose the type of deployment, Farm or Stand-Alone server.
Note: Always use a ADFS Farm in a production environment. When you use a Stand-Alone server you create a hugh single point of failure!
5. Now verify that the correct SSL certificate (the one just created) and Federation Service name (equal to the common name of the certificate) are specified.
The wizard will show a list of changes like the one shown below:

Configuration changes set by ADFS Configuration Wizard

After we’ve run the wizard we’ve partly configured ADFS. To fully configure ADFS for use with Office 365 the “Microsoft Online Services Identity Federation Management Tool” and “Microsoft Online Services Connector” need to be installed on the ADFS Server.
- The 32-bit version of the identity Federation Management tool can be downloaded here, the 64-bit version here.
- The “Microsoft Online Services Connector” can be downloaded from the Office 365 Beta tenant. (you need your own Beta account for it).
Install both tools and let the ”Services Connector” update your system.  After this step all the preparations are done on the on-premise environment and we can commence the actual federation with Office 365.
The below steps will create a new domain in Office 365 and federate it:
1. Open the Microsoft Online Services Identity Federation Management Tool
2. In the PowerShell window enter: $cred = get-credential (this will show a prompt to enter Office 365 credentials)
3. Enter the Office 365 Admin credentials in the prompt which you want the tool to use for the connection to Office 365
4. Enter:  ”Set-MSOLContextCredential -MSOLAdminCredentials $cred” into the tool
5. Then enter: “Add-MSOLFederatedDomain -DomainName “yourdomain.com”
You will see a warning like the one below:

The domain name is now created in Office 365 but it isn’t working yet. First you have to verify that you are the owner of the domain.
This can be done by creating the CNAME record that is shown in the warning you get when performing the 5th step (like the one in the picture above) and point it to ps.microsoftonline.com.
6. Create the CNAME Record in DNS
7. Go back to the Identity Federation Management tool
8. Enter: “Add-MSOLFederatedDomain -DomainName “yourdomain.com” again.
The command in step 8 will read the CNAME record and verify the domainownership. After the domain ownership is verified the domain is federated.
If you would like to review the configuration you can use this command:
Get-MSOLFederationProperty -DomainName “yourdomain.com”
If you already have your domain added to Office365 you have to convert your domain to a federated domain. This can be done by following these steps:
1. Open the Microsoft Online Services Identity Federation Management Tool
2. In the PowerShell window enter: $cred = get-credential (this will show a prompt to enter Office 365 credentials)
3. Enter the Office 365 Admin credentials in the prompt which you want the tool to use for the connection to Office 365
4. Enter:  “Set-MSOLContextCredential -MSOLAdminCredentials $cred” into the tool
5. Then enter: “Convert-MSOLDomainToconverFederated -DomainName “YourdomaininOffice365.com”
After running this command the domain will be changed from a standard authentication to a Federated authentication domain.
This can also be reviewed using the “Get-MSOLFederationProperty” cmdlet.
Have fun federating your domain with Office 365!

Office 365 Issues

Outlook live : Post Time Out issue - http://microsoftblog.co.in/commerceserver/troubleshoot-post-ticket-time-out-exception-2/

Copy pasted from above link
-----------------------------------
The error "Post ticket time window expired.  Ticket could be reposted" indicates the users ticket is no longer valid.  RPS uses POST TICKET TIME WINDOW to prevent Compact Tickets from being accepted if the difference between Compact Ticket "IssueInstant" and server’s Now() time is more than an amount that you specified in RPSServer.xml.
If it is less, then Compact Ticket is accepted. If it is more, then RPS throws PP_E_RPS_REASON_POST_TICKET_TIMEWINDOW_EXPIRED.
The default value for PostTicketTimeWindow is 300 seconds (5 minutes). This is configurable in the RPSServer.xml (which is actual fix). Apart from this, I have catch this error in the code and redirect the user to the Silent Auth URL to refresh the ticket. Sending the user to the Silent Auth URL with a different CT value (current time – matching your servers time), the login server will issue a new compact ticket. Finally the issue the fixed.

-----------------------------------

Configuring trust with Office 365

http://support.microsoft.com/kb/2521057

Using remote PS to manage Office365 Identities

Copied from Blog : http://philwicklund.com/blog/Pages/Using-remote-PowerShell-to-manage-Office-365-identities.aspx

With remote PowerShell you can connect to Office 365 to perform management tasks that are not available or practical in the web management interface. For example, you can use Remote PowerShell to automate repetitive tasks, extract data for custom reports, customize policies, and connect Exchange Online to existing infrastructure and processes. This is especially usefully when you need to perform the same task thousands of times. What would take days through the browser can take minutes with a script. The following is a list of common settings configured with remote PowerShell:

·         User management

·         License assignment

·         Security group management

·         Domain management

·         Admin role assignments

To use Remote PowerShell, your PC must be running the Windows Management Framework, which contains Windows PowerShell v2 and WinRM 2.0. These components are already installed in computers running Windows 7 or Windows Server 2008 R2. You can manually download these components for computers running other operating systems. You do not need to install any Exchange Server management or migration tools in order to use Remote PowerShell, however you will need to download and install the Microsoft Online PowerShell Module.

The Microsoft Online PowerShell Module contains Office 365’s core cmdlets, such as cmdlets to manage users, groups, etc. To download the module use the following links:

X64: http://bit.ly/l8lS9z

X86: http://bit.ly/jTqbJW

To get started, open PowerShell on your PC and run the Import-Module MSOnline cmdlet to load the module you just downloaded and installed. Next, you’ll need to connect to Office 365 using a set of credentials. Use the Get-Credential cmdlet to set your credentials to a variable you can pass into the Connect-MsolService cmdlet . The Connect-MsolService cmdlet passes your credentials to Microsoft Online and sets up the secure connection. Once you’re connected to Microsoft Online, you can start scripting you administrative actions. The figure below shows an example of how to connect to Microsoft Online with PowerShell after you’ve installed the module:

You’ll notice in the figure that the Get-MsolUser cmdlet was executed to fetch all the users in Microsoft Online. From a user management perspective there are many cmdlets you can use. The following scenarios will help you add/remove users, reset passwords, add/remove security groups, enable/disable password expiry, and enable/disable password strength requirements.

Creating a new user

To create a new user, use the New-MsolUser cmdlet. The following is an example of the cmdlet in use:

New-MsolUser -UserPrincipalName john@litwareinc.com -DisplayName "John Doe" -FirstName "John" -LastName "Doe"

Assigning a user a license

When you first create a user, that users doesn’t have a license assigned to them and therefore cannot access SharePoint Online. To assign the use a license you must use the Set-MsolUserLicense cmdlet. However, first you must get the license key you want to assign them through the Get-MsolAccountSku cmdlet. Notice in the figure below the Get-MsolAccountSku cmdlet will return all the licenses you have purchased (ActiveUnits) along with how many of those licenses have been already allocated to users (ConsumedUnits).

With this information available you can run the Set-MsolUserLicense cmdet. Use the AddLicenses parameter to assign a license, and use the RemoveLicenses parameter to remove a license. This can be seen in the example below:

Set-MsolUserLicense -UserPrincipalName user@litwareinc.onmicrosoft.com -AddLicenses "litwareinc: ENTERPRISEPACK" -RemoveLicenses "litwareinc:SHAREPOINTSTANDARD"

Note You can only assign one license to any given user. If you want to upgrade a user’s license, first remove the one they currently have, and then add the new license you want to give them.

Removing a user

You can remove a user by using the Remove-MsolUser cmdlet, as can be seen below:

Remove-MsolUser -UserPrincipalName john@litwareinc.onmicrosoft.com

Resetting a user’s password

Quite commonly users will forget their passwords and they’ll need an administrator to reset it for them. Resetting passwords with PowerShell is quite easy. Simply use the Set-MsolUserPassword cmdlet. Set the NewPassword property if you want to specify a specific password to assign them. You have the option to use the ForceChangePassword property if you don’t want to require the user to change the password when they first log in. If you don’t use the NewPassword property the user will be assigned system generated password. In either case, the user will receive an email with their password after you run the cmdlet.

Set-MsolUserPassword -userPrincipalName john@litwareind.onmicrosoft.com
    -NewPassword "password" -ForceChangePassword $false

Blocking a user

To block a user from accessing Office 365 or SharePoint Online, without permanently deleting the user, use the Set-MsolUser cmdlet and set the BlockCredential property to true:

Set-MsolUser -UserPrincipalName user@ litwareinc.onmicrosoft.com -blockcredential $true

Disabling password expiration for a user

By default all passwords will expire after 90 days. To disable this for a given user use the Set-MsolUser cmdlet and set the PasswordNeverExpires property to true:

Set-MsolUser -UserPrincipalName user@ litwareinc.onmicrosoft.com
    -PasswordNeverExpires $true

Disabling strong password strength requirements

By default all passwords must meet a certain level of complexity. You can disable these complexity requirements on a case by case basis with the Set-MsolUser cmdlet. Simply set the StrongPasswordRequired property to true:

Set-MsolUser -UserPrincipalName user@litwareinc.onmicrosoft.com
    -StrongPasswordRequired $true

Adding a new security group

Security groups in Office 365 are helpful for SharePoint Online users because they can be uses across multiple site collections. SharePoint Groups can only be using in a single site collection, so if you want to manage authentication across more than one site collection a Office 365 security group can be helpful. To create a new group, simply use the New-MsolGroup cmdlet:

New-MsolGroup -DisplayName "Sales Executives" -Description "All sales staff"

Adding users to a security group

To add a user to a group, you can use the Add-MsolGroupMember cmdlet. The problem however is this cmdlet requires a handle to the group you want to add the user to, and to get a handle to that group you first must use the Get-MsolGroup cmdlet and search on the group’s display name:

$salesGroup = Get-MsolGroup | where-object { $_.DisplayName -eq "Sales Executives"}

Note You can use the “SearchString” parameter rather than the where-object option to make searching for a group or user easier, however it may return more than one result, which you wouldn’t want.

After you have your group assigned to a variable you’ll also want a handle on the user you want to add to that group, for example:

$user = Get-MsolUser | where-object { $_.DisplayName -eq "Phil" }

Hereafter can use the Add-MsolGroupMember cmdlet and add a user to that group, for example:

Add-MsolGroupMember -GroupObjectId $salesGroup.ObjectId -GroupMemberType "User"
    -GroupMemberObjectId $user.ObjectId

Deleting a security group

To delete a security group, simply use the Remove-MsolGroup cmdlet, as can be seen below:

Remove-MsolGroup -objectid $salesGroup.ObjectId

Useful Exchange Online and Office365 cmdlet

Copied from Blog : http://gsexdev.blogspot.com/2011/07/running-exchange-online-and-office-365.html

Running Exchange Online and Office365 Powershell cmdlets in C# and managed code

When you’re looking at automating Office365 and Exchange Online from managed code you need to be aware of the 2 sets of cmdlets that you may need to use depending on the tasks that your trying to perform. Most of the administration of ExchangeOnline is done using remote powershell where Exchange Online provides a subset of the normal on-premise Exchange 2010 SP1 cmdlets. The other cmdlet set to be aware of is the MSOnline powershell module which you need download and install http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh124998.aspx. The MSOnline module contains cmdlets to allow administration of the wider Office365 service and perform more of the directory/service and service provider functions more akin to Active directory management in a on premise environment (eg adding users to groups etc).

So when using this from Managed code to use Remote powershell against Exchange Online you use the standard code you would use against an on-premise Exchange 2010 deployment against the endpoint https://ps.outlook.com. With the Office365 MSOnline module you need to load this into a runspace and then firstly use the Connect-MsolService cmdlet to connect to and authenticate against Office365. Then you execute as per normal the desired cmdlets.

Here's some sample code the first sample uses remote powershell to connect to ExchangeOnline.

System.Security.SecureString secureString = new System.Security.SecureString();
string myPassword = "password";
foreach (char c in myPassword)
secureString.AppendChar(c);
PSCredential credential = new PSCredential("glen@domain.com", secureString);
WSManConnectionInfo connectionInfo = new WSManConnectionInfo(new Uri("https://ps.outlook.com/PowerShell-LiveID?PSVersion=2.0"), "http://schemas.microsoft.com/powershell/Microsoft.Exchange", credential);
connectionInfo.AuthenticationMechanism = AuthenticationMechanism.Basic;
connectionInfo.SkipCACheck = true;
connectionInfo.SkipCNCheck = true;

connectionInfo.MaximumConnectionRedirectionCount = 4;
Runspace runspace = System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(connectionInfo);
runspace.Open();
// Make a Get-Mailbox requst using the Server Argument
Command gmGetMailbox = new Command("get-mailbox");
gmGetMailbox.Parameters.Add("ResultSize", "Unlimited");
Pipeline plPileLine = runspace.CreatePipeline();
plPileLine.Commands.Add(gmGetMailbox);
Collection RsResultsresults = plPileLine.Invoke();
Dictionary gmResults = new Dictionary();
foreach (PSObject obj in RsResultsresults)
{
gmResults.Add(obj.Members["WindowsEmailAddress"].Value.ToString(), obj);
}
plPileLine.Stop();
plPileLine.Dispose();

This second example loads the MSOnline powershell module into a runspace

InitialSessionState iss = InitialSessionState.CreateDefault();
iss.ImportPSModule(new[] { "MSOnline" });
using (Runspace psRunSpace = RunspaceFactory.CreateRunspace(iss))
{
psRunSpace.Open();
using (System.Management.Automation.PowerShell powershell = System.Management.Automation.PowerShell.Create())
{
powershell.Runspace = psRunSpace;
Command connect = new Command("Connect-MsolService");
System.Security.SecureString secureString = new System.Security.SecureString();
string myPassword = "password";
foreach (char c in myPassword)
secureString.AppendChar(c);

connect.Parameters.Add("Credential", new PSCredential("glen@domain.com", secureString));
powershell.Commands.AddCommand(connect);
Collection results = null;
Collection errors = null;
results = powershell.Invoke();
errors = powershell.Streams.Error.ReadAll();
powershell.Commands.Clear();
Command getuser = new Command("Get-MsolUser");
getuser.Parameters.Add("MaxResults", 100);
powershell.Commands.AddCommand(getuser);
results = null;
errors = null;
results = powershell.Invoke();
}
}
}