The script will look through the a selected Organization Unit and verify that all users have a Home Directory set, and that it has the appropriate NTFS permissions.
Previously all users had Full-permissions on their home folder, which led to the users resetting permissions and removing unwanted permissions (Backup or Admin accounts) to their “private” stuff.
We’ve all been there, wireless passwords tend get lost.
There are several tools to retrieve the missing information, but I strongly believe that the less stuff you download from the web, the safer you are. So why not use the built in functions instead?
By default DirSync runs every three hours; which for some environments or during testing may not be frequent enough…
Windows Server 2012 includes .NET Framework, it provides a comprehensive and consistent programming model to build and run applications (including Roles and Features) that are built for various platforms.
It is not recommended to uninstall .NET Framework. In some given circumstances, there may be a requirement to remove/re-install it…
You must install the appropriate version of the Windows Azure AD Module for Windows PowerShell for your operating system from the Microsoft Download Center.
Once installed you can start the Windows Azure Active Directory Module for Windows PowerShell.
Per default the calendars of shared mailboxes in Office 364 have “FreeBusyTimeOnly” permissions applied.
You could create a new sharing policy and change the applied policy on those accounts.
I however chose to just change the sharing permissions on the shared calendar.
To help detect and prevent malicious behavior I usually implement different scripts or other monitoring features in my customers environments.
One of the snippets I frequently use is one that detects newly created accounts.
There are several reasons to change the default organizational unit of computers that join the domain.
The default OU (domain.local\Computers) cannot be linked with GPOs, and should be avoided since its builtin.
I was getting an error at startup on a new Windows 2008 R2 Domain Controller. Apparently the WinRM attempts to create two SPNs after the startup process.
Since that WinRM runs under “Network Service” account, I was able to fix this warning by granting the “Validated Write to Service Principal Name” permission to the NETWORK SERVICE…
The GUI at Microsoft is great but sometimes we need to dig a bit deeper.
I ran into some issues with a Resource mailbox and had to do some troubleshooting in the Office 365 service.