People, Technology, Connected

ICACLS and Server 2008 R2

David — Wed, 01 Aug 2012 17:27:29 +0000

Contrary to some documentation out there in the internet ethers (how great icacls is compared to its predecessor, cacls), icacls has a serious flaw in bulk processing on server 2008 r2. As a followup to a post I wrote a year ago , I discovered that icacls does not set permissions properly when scripting acl’s in bulk. Here’s my scenario:

Last July I changed employers, and one of my tasks in the past year was to deploy a new file server to replace a very badly configured, poorly deployed virtual machine file server. In addition, I discovered five different naming conventions were used when previous accounts were created in Active Directory. So, to get to a place where I can also prepare for an Exchange migration, I had a lot of account clean up.

Step one was to establish a new naming convention. What’s worked well in the past is firtname.lastname, so obviously home folders would be named identically. When I ran my original cacls script, server 2008 r2 offered me a wonderful alert: “cacls is now deprecated, please use icacls”. Odd, I remember running cacls on server 2008, without issue. R2 is full of surprises

I am of the firm belief that giving users FULL access to their home folders is a really, really bad thing. I have learned over the years that 1) folks out there don’t understand why “Administrator” (or domain admins) has access to their private data in their home folder and 2) when given the power to set permissions themselves, they often remove the Administrator (or group) from their folder, wreaking havoc on backups etc. Anyway, I set MODIFY perms for all home folders for end users…

So, it turns out that a simple:

ICACLS.exe /GRANT MyDomain\user:M /GRANT MyDomain\Domain Admins:F

won’t work on SOME folders. Digging in a bit, I noticed I needed the /grant:r , with the “r” meaning to “replace” the permissions if the ACL is already set for that particular user SID. Great, I thought. And off I went, only to discover that the /grant:r does not replace the ACL as advertised. This really baffled me for a bit and after an early morning awakening (yeah, I dream about this stuff sometimes), I had an epiphany.

In Checking the standard security tab I saw that a user still had FULL access, indicating the script did not work. But when clicking on the advanced button, there it was…the user also had a separate ACL with MODIFY access. So, to make the process work correctly, I had to break it into two separate scripts, one to remove all ACL’s assigned to the user, then add the ACL back with the correct perms. Obviously, running the below scripts should be done OFF hours, as the first one removes ALL access for users to their home folders.

Script 1: For /D %%I in (*) DO ICACLS.exe %%I /remove MYDOMAIN\%%I

Script 2: For /D %%I in (*) DO ICACLS.exe %%I /GRANT:r MYDOMAIN\%%I:(CI)(OI)M /GRANT:r MYDOMAIN\Domain Admins:(CI)(OI)F

Now, I am not sure if it was my mistake in the first place when I ran a simple /GRANT or if ICACLS just doesn’t remove the ACL’s on Server 2008 R2 (as purported), but the above is what worked for me. Hope this helps someone else out there when it comes to the inconsistent processing of ICACLS.

Set Individual User Permissions on Folders Based on Username

David — Wed, 08 Jun 2011 03:15:19 +0000

On a recent endeavor, I needed to create 1400+ folders on a file share named staffweb (part of our domain migration). Essentially, the permissions on the staffweb folder enable www access to each individual’s published content (via IIS). The server OS which houses the share is Server 08 R2, which was particularly frustrating at first because I could not use the standard xcacls.exe to set the permissions when the folders were created. Where the script worked fine on Server 03, it just wouldn’t work on Server 08. By using a combination of scripts, I accomplished the task, but ironically, I had to break out some old school scripting techniques to set the ACL’s properly. Below are both scripts…

The script to create the folders is as follows:

ON ERROR RESUME NEXT

‘Set AD Connection Parameters, get info.
Set objConnection = CreateObject(“ADODB.Connection”)
objConnection.Open “Provider=ADsDSOObject;”

Set objCommand = CreateObject(“ADODB.Command”)
objCommand.ActiveConnection = objConnection
objCommand.Properties(“Page Size”) = 80000

objCommand.CommandText = _
“<LDAP://ou=Staff,ou=District,dc=my,dc=work,dc=domain,dc=here>;” & _
“(&(objectCategory=person)(objectClass=user));” & _
“ADsPath, sAMAccountName, userAccountControl;subtree”

Set objRecordSet = objCommand.Execute
Set fso = CreateObject(“Scripting.FileSystemObject”)

Const ADS_UF_ACCOUNTDISABLE = 2

While Not objRecordset.EOF
strUserName = objRecordset.Fields(“sAMAccountName”)
strADsPath = objRecordset.Fields(“ADsPath”)

strWebDir = “\\test\staffweb\” & strUsername
intUAC = ObjRecordset.Fields(“userAccountControl”)

if intUAC AND ADS_UF_ACCOUNTDISABLE Then
Wscript.Echo strUsername & “: Account Disabled”
End If

‘Create Web Folder
If Not fso.FolderExists(strWebDir) Then
Set fldUserWebdir = fso.CreateFolder(strWebDir)
Set wshShell = WScript.CreateObject(“Wscript.Shell”)

Wscript.Echo strUsername & “: Web Folder Created at ” & strWebDir
Else
Wscript.Echo strUsername & “: Web Folder already exists”
End If

objRecordset.MoveNext
Wend

Wscript.Echo ” ”
Wscript.Echo objRecordSet.RecordCount & ” user accounts checked.”

objConnection.Close

The above script (Special thanks to JShaw) reads AD for pertinent information and creates the folders on a server named “test” and in the share named “staffweb” according to the username found. I have removed the lines where I attempt to have XCACLS set the ACL’s.

The next script needs to be setup as a batch file (filename.bat), set into the root of the staffweb shared folder. It matches folder names against directory names and then edits the permissions to add both the username (in this case firstname.lastname) and administrator with change and full permissions respectively. The /E flag preserves inheritance by adding, not replacing permissions. Run the script from the command prompt.

For /D %%I in (*) DO CACLS.exe “%%I” /T /E /P “mydomain\%%I”:C “mydomain\Administrator”:F
:exit

That’s it, all folders are created based on usernames and permissions are set accordingly.

UPDATE: Server 2008 R2 File Servers:

CACLS is depricated in Server 2008 R2 and the above batch script no longer works. Instead, use ICACLS and adjust the script accordingly:

For /D %%I in (*) DO ICACLS.exe %%I /GRANT MyDomain\%%I:(CI)(OI)M /GRANT MyDomain\Administrator:(CI)(OI)F

Do read the ICACLS help file for the inheritance parameters. The above script keeps inheritance from the container (CI) and object(OI).

How to Create a Shared Calendar with Published Content in Exchange 2010 SP1

David — Mon, 02 May 2011 03:49:24 +0000

One item of importance for a school district is for folks at schools to be able to publish calendars to the web, either to a blog, wiki, or school site. In my attempt to track down a simple How To on the topic, I did not find the specific steps to accomplishing task, so I have opted to create this one. Keep in mind that this method of publishing calendar content to the web essentially replaces the legacy public folders seen in previous versions of exchange server. As part of this How To, I have added the steps to add designated editors of a shared calendar. These are the steps I followed…

Create a Room or Equipment Mailbox in the EMC

Allow Publishing: Go to properties of the new mailbox, then Mailbox Setting Tab, then Sharing. Change the policy to the sharing policy created using the method published here (enter URL of published Document Here)

Convert to a shared mailbox using EMS:

Set-Mailbox “mailboxname” -Type Shared

Add Permissions:

Add-MailboxFolderPermission –identity mailboxname:\calendar –user designatededitorusername -accessrights editor

Repeat command substituting designated editor username accordingly

Enable Publishing:

Before performing this step, you must add the customized sharing policy previously created.

Set-MailboxCalendarFolder –identity mailboxname:\calendar –detaillevel fulldetails –publishdaterangefrom oneyear –publishdaterangeto oneyear –publishenabled $true

Check/Get the published URL: Get-MailboxCalendarFolder mailboxname:\calendar

Add permissions for editor to load the mailbox and alter sharing permissions or republish if necessary:

Add-MailboxPermission –identity mailboxname –user designatedfullaccessuser –AccessRights FullAccess

Add permissions so designated user can send links out via email:

Add-ADPermission –identity ‘mailboxname’ –user ‘designatedsendasaccessuser’ –ExtendedRights ‘Send As’

Once this is setup, the designated user would load the shared mailbox and publish the calendar. Once published, the URL is viewable, which can be sent out via an email.

How to Set Room Resource Policy so Delegates Get Properly Notified

David — Sat, 23 Apr 2011 03:05:25 +0000

A recent query to the Exchange forums suggested that the documentation from Microsoft regarding Room Resource Policy with Delegates is not complete. Upon further review, I discovered the process is rather simple, but not intuitive nor well documented…

Create the Resource (room mailbox, equipment mailbox).
On Resource Policy Tab, select delegate, check “forward meeting requests to delegates”.
On Resource General Tab, check the box for booking attendant.
On the Resource In-Policy Requests Tab, check radio buttons:
1. Selected Recipients (automatic approval), leave blank.
2. All Users (subject to approval)

On the Resource Out-of-Policy Requests Tab, check “Selected recipients”. Leave blank

*Note: My goal was to have all meeting requests forwarded properly to the delegate(s) for approval, whether it’s in policy or out-of-policy. The above steps accomplish this however, if you desire to have only out-of-resource policy requests forwarded to a delegate AND all in-policy requests auto-accept, then use the Microsoft suggested defaults.

Basics of Internet Calendar Sharing in Exchange 2010 SP1

David — Wed, 16 Mar 2011 03:05:11 +0000

One very important aspect of calendar management is the ability to have globally shared calendar information available for publication to the internet or an intranet. To accomplish this, certain requirements must be met prior to publicly or privately “publishing” shared calendar information. The following are some basics that an Exchange administrator will need to know in order to successfully create publishable calendar content.

With Exchange 2010 SP1, a new virtual directory was added specifically for calendar sharing and the default settings should be set accordingly. To verify the settings prior to proceeding, open an EMS and type:

Get-OwaVirtualDirectory |select name, server, calendar*

This will provide the output verifying that all CAS servers have the CalendarPublishingEnabled flag set to True.

Next, an Internet Calendar Sharing Policy needs to be created:

Open EMC, go to Organization Configuration, Mailbox
Click the Sharing Policies Tab
From the right Actions pane, select “New Sharing Policy…”
The New Sharing Policy Wizard starts. Give the new policy a name, then click the Add button in the Assign Actions section. By default the checkbox to enable the policy is set.
The Add Action to Sharing Policy Domain window pops up
**This is important** -type Anonymous in the top line, and then select “Calendar sharing with free/busy information plus subject, location, and body.

Click Ok, then next, and next on the New Sharing Policy Wizard window. The policy will be created.

Next, open the properties on any global shared calendar you want to enable publishing on under Recipient Configuration.

Select the Mailbox Setting tab and then Sharing.

Apply the sharing policy that you just created by clicking Browse… and select it from the list.

That’s it, you have now created a new internet calendar sharing policy and have assigned it to a global shared calendar.

How to set access rights for calendars in Exchange 2010

David — Sat, 08 Jan 2011 12:00:00 +0000

Since most of our users at work run on Macintosh, we have them use OWA exclusively. One caveat to doing so revealed a hope-to-be-resolved-soon bug which no doubt other OWA users will observe along the way-a user cannot share their calender with permissions greater than “Reviewer”. The workaround at the moment requires server-side resolution, which from a sysadmin’s perspective, is not welcomed overhead in managing an already expansive system such as Exchange. It is easy enough however, to extend permissions on user’s calendars. The following is an outline to do just that:

Cmdlets used:

Get-MailboxFolderPermission

Add-MailboxFolderPermission

Remove-MailboxFolderPermission-(this cmdlet is used to remove an existing coworker who was added before discovering it cannot be done in OWA).

Examples:

Get-MailboxFolderPermission –identity david.bolton:\calendar

Remove-MailboxFolderPermission –identity david.bolton:\calendar –user my.coworker

Add-MailboxFolderPermission –identity david.bolton:\calendar –user my.coworker –accessrights editor

AccessRights Parameter = roles assigned

Roles Assigned:

- Owner CreateItems, ReadItems, CreateSubfolders, FolderOwner, FolderContact, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
- PublishingEditor CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
- Editor CreateItems, ReadItems, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
- PublishingAuthor CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, DeleteOwnedItems
- Author CreateItems, ReadItems, FolderVisible, EditOwnedItems, DeleteOwnedItems
- NonEditingAuthor CreateItems, ReadItems, FolderVisible
- Reviewer ReadItems, FolderVisible
- Contributor CreateItems, FolderVisible

Custom MMC’s on Terminal Server

David — Fri, 07 Jan 2011 19:09:52 +0000

I am a huge believer in managing Active Directory from both a centralized and decentralized mode. I work in an environment where we have a 9 to 1 ratio of Macintosh versus PC based systems. We needed to give specific people, specific access to parts of Active Directory so they could essentially fill the role of helpdesk (since this position no longer exists in our department). Without being able to give them an ADUC client (Mac), we needed to come up with another solution. Creating a terminal server with customized MMC’s which launch at login and according to their group is what we were after. The following is the quick and easy setup of such.

The first piece of this process was to get the terminal server up and running. Once that was done (in short time thanks to our VMWare environment) and proper permissions were setup for access to it, I moved on to create the custom MMC’s. When I say custom, I mean an MMC that gives the user an interface that shows only that section of Active Directory which they need access to in order to complete specific tasks such as disable accounts, reset passwords, or view properties of an account. I will not go into details here on how to create customized MMC’s as there is a ton of information out there on the net for such. However, I will say that I simply author an MMC in a new taskpad view and assign only those tasks needed for the individuals, then lock the entire MMC down at completion.

Once the set of MMC’s was created for multiple folks at multiple locations, I needed a way to launch only that MMC on the terminal server when they login. For each location, an assigned user should get only their MMC. Thus, a simple script to run at login, called from the local group policy was the solution. The following is the script syntax, customize for your situation:

@echo off REM Launch MMC according to user’s group membership

:SITE1
ifmember “site1 student admins”
if not errorlevel 1 goto SITE2
start c:\MMCs\SITE1.msc

:SITE2
ifmember “site2 student admins”
if not errorlevel 1 goto SITE3
start c:\\MMCs\SITE2.msc

:SITE3
ifmember “site3 student admins”
if not errorlevel 1 goto TechSvcs
start c:\\MMCs\SITE3.msc

:TechSvcs
ifmember “technology services staff”
if not errorlevel 1 goto quit
start c:\\MMCs\Tech.msc
start c:\\MMCs\AdminGuest.msc

:quit

As you can see, you can call multiple MMC’s at one time (the tech services section), giving folks further access into Active Directory as needed. The last piece of this is to name this script something like LauchMMC.bat, and add it as a login script (User Configuration) through the local Group Policy editor.

php5-filter (missing header) issue resolved…

David — Tue, 28 Dec 2010 00:32:14 +0000

On a recent portupgrade I received some dreaded ***stop error***’s regarding php5-filter and php5-zip ports. The output was as follows:

“Skipping ‘lang/php5-extensions’ (php5-extensions-1.3) because a requisite package ‘php5-zip-5.2.12′ (archivers/php5-zip)
failed (specify -k to force)
** Listing the failed packages (-:ignored / *:skipped / !:failed)
- devel/automake110 (port directory error)
- devel/automake19 (port directory error)
! devel/autoconf (autoconf-2.62) (install error)
* devel/autoconf (autoconf-2.67)
* lang/php5 (php5-pcre-5.2.12)
* lang/php5 (php5-spl-5.2.12)
! security/php5-filter (php5-filter-5.2.12) (missing header)
! archivers/php5-zip (php5-zip-5.2.12) (missing header)
* lang/php5-extensions (php5-extensions-1.3)”

At first, I needed to resolve the autoconf issue and a pkg_info *auto yeilded some interesting information-four different versions of each with separate wrappers. Apparently devel/autotools has had some ongoing cleanup taking place, which AHEM (yes, I make bonehead sysadmin mistakes too , I failed to catch while reading the /usr/ports/UPDATING file prior to running portugrade…

Specfically, the UPDATING file reads:

“IMPORTANT: if you have either devel/autoconf-wrapper or
devel/automake-wrapper installed on your system (and you most likely do)
PLEASE update these ports to their new versions before updating anything
else — Bad Things[tm] are likely to happen otherwise.”

So off to Google I went in an effort to resolve the issue. Well, not much help there so based on my past experience, I know autoconf/automake are required packages on many other ports. I uninstalled the autoconf and automake ports and will let package dependencies resolve the issue on future upgrades.

After dealing with autoconf/automake, it was on to the php5 errors. Noticing that the errors originally had to do with pcre, and after checking the /usr/ports/MOVED file I noticed this little entry on php5-filter:

“security/pecl-filter|security/php5-filter|2008-12-11|Now bundled in php5″.

Hmmm, maybe I am on to something here. I noticed also that pecl-filter was its own package previously (pkg_info) and listed as such.

To finally resolve the pcre and pecl-filter issue, and to get to the point of fixing the php5 issue, I did the following:

pkg_delete -f pecl-fileinfo-1.0.4
pkg_delete -f php5*
accordingly I added WITH_BUNDLED_PCRE=”YES” in my make.conf file (http://forums.freebsd.org/showthread.php?t=13191)
cd /usr/local/
rm /etc/php.*
rm -r lib/php/
rm -r /include/php/
cd /usr/ports/lang/php5/
make rmconfig
make install clean, selecting options I needed for re-install of php5
cd ../php5-extensions/
make install clean
and finally, pkgdb -Fu to remove any outstanding port dependencies (which no fix was necessary)

No further errors were thrown and our production blog server is back to being very happy

RDCman – Great New Addition To The Sysadmin’s Toolbox

David — Wed, 16 Jun 2010 03:14:30 +0000

While polling the microsoft exchange team site recently, I found this post about an internal tool the dev team has available to them, which recently has been made public. After a quick download and setup of RDCman, I was off and running. I exported my current list of servers straight out of “remote desktops” tool and directly into rdcman. Once some intitial editing was done for credentials to each server (we have two domains, each with different admin credentials), it was time to check it out.

The first thing I noticed was the fact that you can setup different groups (to be used as a lab manager) or you can add an entire server list as I did. A great feature of this tool is that credentials can be inherited directly from the top of the server list (global), as well as local resource settings, gateway, file, connection, security, and display settings.

This tool really rocks, and I probably won’t ever go back to using the standard “remote desktops” tool. I love the thumbnail view and at a moments glance can view all servers that are either in a connected or disconnected state, as you can see from this screenshot:

One quirk I noticed though is that in thumbnail view you can actually click inside an open server, which is live in thumbnail view. The problem I see with this is that one could easily open, close, or delete items without being fully aware of their actions. I quickly learned this as my first inclination was to double-click to expand the thumbnail window and noticed I was about to remove a database! The resolution is simply to click on the live server in the left pane.

Check out some more details here: http://msexchangeteam.com/archive/2010/06/11/455115.aspx

and you can download the tool here: http://www.microsoft.com/downloads/details.aspx?FamilyID=4603c621-6de7-4ccb-9f51-d53dc7e48047&displaylang=en

Enjoy!

Losing a whole year…

David — Sun, 16 May 2010 03:35:12 +0000

Well, I can’t believe it has been an entire year since I last posted on this blog. I have a ton of learning to convey and just haven’t had the time. On a personal note, I began taking care of two parents who were both diagnosed with Alzheimer’s back in mid 2008. Trying to keep up with my own family (wife and two kids) and add to that all of my parent’s affairs, well my life has just been crazy. Thinking about blogging, but just never getting to it.

The VMWare cluster implementation is complete and I will add some posts about that. As I move towards a full IMAP to Exchange 2010 implementation, I will add posts regarding those processes as well. I moved from my iPhone to Droid recently and quite honestly, will probably never go back . I will post my findings on that as well.

Stay tuned…