Changing Office365 password policy with PowerShell

I want to spend some words about changing password policy in Office 365, where ADFS is not installed. In these cases, we have usually two passwords – one for local system and one for online environment. This is an exception in Essentials server, because it is possible to synchronize on premise and online environment, but we can do some nice things also in other environments with few PowerShell commands. The thing that is really not good and is not possible to change is the password structure. We must preserve password 8 to 16 characters long and with allowed characters (http://community.office365.com/en-us/wikis/administration/characters-in-passwords-or-user-names-in-office-365.aspx).
Anyway, you can change some settings like password age, password expiration and you can do this for user or for domain. The first thing, that you have to do, is install Office 365 cmdlets from this link (http://onlinehelp.microsoft.com/office365-enterprises/hh124998.aspx). On this point, you have to install two things: Microsoft Online Services Sign-In Assistant and Microsoft Online Services Module for Windows PowerShell. After this operation,you are ready to begin.
The first step to do is connecting to Office 365 environment. For this you need three simple PowerShell commands and credentials of administrative account:
Import-Module MSOnline
$O365Cred = Get-Credential
Connect-MsolService -Credential $O365Cred
After this you can change password policy with command Set-MsolPasswordPolicy -ValidityPeriod 60 -NotificationDays 14 -DomainName domain.com, which will change policy for domain named domain.com. The password validity period will be 60 days with notification to change password 14 days before it will expire.
If you want to set password never expire to user, you have to do user by user with command Set-MsolUser -UserPrincipalName <user ID> -PasswordNeverExpires $true. Of course is possible to automate also this task and for example, if you want to do this step for all users it is very simple: Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $true.

Good work..

Windows Server 2012 Essentials is now RTM

Today Microsoft published the RTM version of Windows Server 2012 Essentials. Download is available on MSDN for Microsoft partners. The new version is similar to the old one, with some new features (like the connector for on premise Exchange, Cloud backup …). This version is also a replacement for Home server, which means that now are available Media functions (similar as that in Home server).
Good, now you have enough reasons to download it. Test and enjoy it!.

Update Windows 8 and Windows Server 2012 with WSUS 3.0

Now many of us are using Windows 8 and Windows Server 2012. In many cases, there are some problems updating these operating systems with WSUS 3.0. The first symptom is, that these systems are reported in WSUS as Windows XP pro, not as Windows 8. It seems that the problem is in WSUS service. To solve the problem you must install WSUS SP2, which is downloadable from http://www.microsoft.com/en-za/download/details.aspx?id=30747 (64bit) or from http://www.microsoft.com/en-za/download/details.aspx?id=30748 (32bit).
After installing this update, you will be able to update the Windows 8 and Server 2012 operating systems..

Essentials and SBS Server RWA Security

I have to say that I have reported the same problem in Windows Server 2012 Essentials as I had reported it two years ago for SBS Standard 2011 and SBS Essentials 2011. Unfortunately also in this case I had from Microsoft people the answer, that this is »feature by design«.
The explanation of the problem is simple. In any Microsoft environment, administrator does not have the access to other users’ redirected folders. For me, this is a right approach (of course the user can have in this folder some private data and we must leave them as that). The same thing is in Essentials server; administrator, in the way of browsing on server, is not able to access to other users’ folders.

We can see, that this is the same approach like in other products and is the same approach as is in server environment at least since Windows server 2000. It gives privacy and confidence to all users for their data, because they are secure.

In other way,if you try to access to the same data true RWA,you will get a surprise. You can access to all users’ folders, and also to any shared folder.

It does not depend on security settings, it is simply accessible. Do you think, that this will help to inspire confidence in users? I don’t think so.
What does Microsoft say? They are sure, that this is a small environment, where administrator must have access to data for support reason (OK, but to private files?). I might try to understand them, but this state as is now, sounds like “Sorry Mr. User, I cannot help you from your office. If you like my help, I can do this from home.” This is not a clear situation. In most cases you cannot access to personal data like in “real systems”, but it exists a work around (which is not a trusted computing approach). We have two very different types of understanding what are and how to secure users personal data. This is not the right way and I think that is not clearly defined what administrator can do and what he can’t do.
So once again, please let me know what do you think about this and also tell the same things to Microsoft people via connect site or forums. It will be the best thing for us and our customers..

Applications are not visible in RDWEB access

Sometimes applications can not be visible in Remote desktop web access. It looks that they are deployed and published correctly, you are able to connect to them via Remote app. In these cases I found mostly two different problems:
First problem
Server, that is hosting the RD Web application website, is not a member of Windows Authorization Access Group. RD Web Access server directly queries the servers and filters the retrieved list of RemoteApp programs based on the ACLs and needs permissions to do that. To solve or control this settings do the following steps:

  • Open the Active Directory Users and Computers, expand the console and find the name of RD Web Access server.
  • Right-click on it and select Properties, then in Member Of tab, add the Windows Authorization Access Group.

Second problem
Security settings in WMI control are not correct. Also this issue is easy to fix:

  • On the server, that is hosting RD Web Access, open start menu and run WMIMGMT.MSC.
  • Right-Click on WMI Control (Local) and select Properties.
  • Expand Root, CIMV2 and click on TerminalServices.
  • Click on Security and look for TS Web Access Computers (COMPUTERNAME TS Web Access Computers).
  • If TS Web Access Computers group is not present, then add it.
  • Add the Execute Methods, Enable Account and Remote Enable rights to this group.

After this check the RD Web Applications in most cases work.

Future reading: http://blogs.msdn.com/b/rds/archive/2009/06/12/introducing-remoteapp-user-assignment.aspx.