I wrote my very first PowerShell script today which I wanted to share. I’m definitely no PowerShell guru; in fact, the only times I’d ever used Powershell before is to run a script someone else has written. I have never written even one line of a PowerShell script before but I had to do so today. Basically, I needed to write something to quickly turn all my MOSS 2007 site collections into read-only mode. Since we’re talking about hundreds of site collections here, there was no way I was going to do this manually. In Service Pack 2 for WSS/MOSS, the setsitelockSTSADM operation was added to allow you to specify a lock type on a site collection. I knew I could use this and combine it with the enumsitesSTSADM operation to quickly turn my site collections into read-only mode and then later turn it back into ‘normal’ mode.

Below is my script. Remember that again, this is my first PowerShell script and I needed to get it done quickly so be gentle in the critique ;).

Script: setsitelock.ps1

   1: param([string]$lockmode, [string[]]$webappurls)

   2:  

   3: $arrLockModes = "none", "noadditions", "readonly", "noaccess"

   4:  

   5: if ($lockmode -eq "" -or $webappurls -eq $null)

   6: {

   7:     Write-Host -foregroundcolor red "Either lockmode or webappurls not specified. Usage: setsitelock -mode {none|noadditions|readonly|noaccess} -webappurls url1,url2,url3"

   8: }

   9: elseif ($arrLockModes -notcontains $lockmode)

  10: {

  11:     Write-Host -foregroundcolor red "Incorrect -lockmode specified. Valid lockmodes are: $arrLockModes"

  12: }

  13: else

  14: {

  15:     foreach($webappurl in $webappurls)

  16:     {

  17:         Write-Host "Setting site lock for site collections in $webappurl to $lockmode."

  18:         $rawdata=stsadm -o enumsites -url $webappurl

  19:         $sitesxml=[XML]$rawdata

  20:         

  21:         foreach($site in $sitesxml.sites.site)

  22:         {

  23:             $scurl= $site.url

  24:             Write-host -foregroundcolor yellow "`tSite collection: $scurl"

  25:             $msg = stsadm -o setsitelock -url $scurl -lock $lockmode

  26:             

  27:             if ($msg -match "Operation completed successfully") {$fgcolor="Green"}

  28:             else {$fgcolor="Red"}

  29:  

  30:             Write-host -ForegroundColor $fgcolor "`t`t$msg"

  31:         }

  32:     }

  33: }

To run the script, just save the script to a directory, open up the PowerShell console, navigate to the directory and run:

.\setsitelock.ps1 –lockmode {none|noadditions|readonly|noaccess} –webappurls “app_url_1”, “app_url_2”, “app_url_3”, etc.

 The actual file: setsitelock.zip (624.00 bytes)

In the first part of this series, I showed you how to create a new Team Project Collection in TFS and the new SharePoint site collection and SSRS reports folder created for the site collection. In this part, I will show you how to create a TFS Team Project in the Team Project Collection, add team members to the project, manage permissions on the SharePoint site and review the SSRS report security settings.

Part 2A: Creating a team project.

1. Open Visual Studio 2010 and click on Connect to Team Foundation Server.

2.  Select the TFS server and select the Team Project Collection that we created in Part 1 and click the Connect button.

3. Create a new Team Project in the Team Project Collection. In the Team Explorer pane, right-click on the Team Project Collection and select New Team Project.

4. In the wizard that opens, specify the name and description of the new project.

5. Specify the Process Template to use for the project. Out of the box, there are two process templates available: MSF for Agile Software Development v5.0 and MSF for CMMI Process Improvement v5.0. For this project, I’m going to use the MSF for Agile Software Development v5.0 template. To understand the differences between the two templates, refer to the documentation located here: http://msdn.microsoft.com/en-us/vstudio/aa718795.aspx. Note, you can also download additional process templates or create your own process template using the Process Editor (part of the TFS Power Tools). This is available at the above link.

6. Allow the New Project wizard to create the SharePoint site that will be used as the portal for this project. The site will be created under the site collection that was created for the Team Project Collection.

7. The wizard will create a new source control folder in TFS.

8. Review the new Team Project settings.

9. Click the Finish button.

10. Close the wizard after the project is created.

Part 2B: Managing Team Members and Permissions

1. In Team Explorer, find the new project we just created and right-click on Team Members. You can give users access to the team by clicking on the Add Team Member  option. You can also create sub-teams by selecting the New Subteam option. For this project,  we will create the following subteams: Business Analysts, Developers, Project Managers, and Testers.

2. Add the appropriate members to each sub-team by right-clicking on each sub-team name and selecting the Add Team Member option from the menu. These members will all be added to the Team Project’s Contribute security group. To modify or reassign them to a different security group, right-click on the team project name and select Team Project Settings –> Group Membership.

3. In order to make sure the team members can access the project portal, you need to go into the SharePoint site and give the users you added to the team permissions to the site. In the Team Explorer window, right-click on the project name and select Show Project Portal. This will open the SharePoint site that was created for this project.

14. Go to Site Actions –> Site Permissions to grant access to this site for the project team members. You can create groups, custom permission levels, etc just like permission management in any other SharePoint site. In this case, I’m going to just grant each team member Contribute permissions for this site.

Part 2C: Reviewing SSRS Security

1. In the SharePoint site, click the Reports link in the Quick Launch menu on the left. You will be taken to the SSRS reports folder specific to the new project. There different folders for the different reports. The reports available are based on the process template you selected when creating the Team Project. By default, for the Agile-based process template, there are reports for Bugs, Builds, Project Management, and Tests.

2. You can also manage the security of a report folder or report. Hover over a folder or report and select Security from the drop-down menu. Select Edit Item Security from the toolbar. You will be asked to confirm that you actually want to break permission-inheritance for the object.

3. By either clicking on the New Role Assignment toolbar item or clicking Edit next to an existing Group or User, you can change with Role Assignment for the group or user. The main roles are: Browser (read-access), Publisher (create reports), and Content Manager (manages the report server content for the project).

Team Foundation Server (TFS) 2010 and SharePoint 2010 are excellent tools to use for managing projects and applications. In this series on Application Lifecycle Management (ALM), I will show you from start to finish how to manage your projects in TFS 2010 and SharePoint 2010. For this example, I will use these tools to manage the creation of a new SharePoint 2010 intranet portal for my company, DeviantPoint.

This series does not cover installation and configuration of TFS, SharePoint 2010, and SQL Server 2008 R2 Reporting Services. Those are topics I may cover in a future post. However, here are some fairly good resources that should help you get started with that:

• Team Foundation Server Installation Guide for Visual Studio 2010
• SharePoint Server 2010 Three-tier farm installation
• SharePoint Products and Team Foundation Sever
• Reporting Services in SQL Server 2008 White Paper (Installation and Configuration instructions)
• Adding a Report Server to a Team Project Collection
  

Part 1: Creating a Team Project Collection

1. Open the Team Foundation Administration Console.
2. Create a new collection under Server –> Application Tier –> Team Project Collections.
3. Click Create Collection.

4. Provide a name and description for the new Project Collection.

5. Specify the data tier (SQL Server and database name).

6. Specify the SharePoint web application and path to new site collection.

7. Specify the SQL Server Reporting Services server. Note that TFS doesn’t work with SSRS SharePoint Integrated mode. In my environment, I have two SSRS servers, one that runs in SharePoint Integrated mode (for my BI-related demos) and one that doesn’t. Here, I’m specifying the URL to the Reporting Services server that doesn’t run in integrated mode.

8. Configure the Lab Management (not currently configured in my environment)

9. Review the Configuration and make changes as necessary.

10. Run Readiness Check.

11. Create the new Team Project Collection.

12. Close the wizard.

12. Review the top-level site collection created in SharePoint.

13. Review SQL Server Reporting Services.

I've been meaning to post this for at least a month but I've been so busy with work that I've had no time to sit down and write this until now. But better late than never, I guess.

A little more than a year ago, I developed a browser-enabled InfoPath form that was used on a public-facing MOSS site so that site visitors could submit their photographs to the organization's yearly photo contest. Along with capturing the photo metadata (title, location, date, etc), one of the fields on the form was for the photo itself, captured through the use of the attachment control. The photo contest reviewers wanted to be able to have a quick and easy way to review the photos and the photo metadata so the original thought was to submit the photo to a document library and use property promotion to display the photo along with the metadata. Unfortunately, we quickly found out that the attachment control could not be promoted to a property. So I wrote a web service instead that would accept this form, extract out the attachment, and save the attachment directly into a picture library (and copy the photo metadata as well). That way, the users were able to see the photo and its metadata as soon as they opened the library.

A few months ago, someone again approached me with similar requirements. They were building a form that would have an attachment field that they'd need to extract to put into another library. Well, that was enough right there to make me realize that I needed to build something that would enable users to build these types of solutions themselves. I didn't want to have to keep writing things over and over to support these types of requirements. I also wanted to remove myself out of the process; they were already at 90% of the entire solution since they were building these forms already, they just needed the last 10% of being able to extract the attachment.

So what I ended building instead was a new workflow activity that could be used in SharePoint Designer as a workflow action. Basically, the action can be used as part of a workflow created in SharePoint Designer that will allow the user to add a step in their workflow for extracting out the attachment and saving it somewhere else. When the action is added to the SPD workflow, it looks like the following:

The 'attachment field name' is where the user specifies the name of the attachment control field in the InfoPath form. The link 'the item' is the SharePoint list item this action should work against. This is going to typically be the current item. The 'document library' is where you want the item to be stored to and the 'filename' parameter is the filename to save the attachment as (this can be driven dynamically as well from metadata of the item or some variable). The sentence '(use attachment name instead: Yes)' actually gives you the opportunity to use the actual filename of the file that was attached, rather than having to specify the filename yourself. When a user attaches a document to an InfoPath form, part of what is stored is the actual file's filename. Though that is not available through SharePoint, it can be extracted out by code, which I do inside of the custom action. By specifying 'Yes' for this field, this indicates the action to ignore the filename parameter and use the attachment's filename instead. The workflow designer can also specify whether or not the file should overwrite any existing file in the document library with the same filename. Finally, when the attachment has been extracted and saved, the action returns the item's new id which can be bound to a variable in the SPD workflow.

As an example of how this works, I created a sample New Hire InfoPath Form. The form contains an attachment field for an employee photo. The forms are submitted to my 'New Hire Forms' document library. Here is a sample of the form as it's been filled out:

Now, let's say that as part of this scenario, I want to give others the ability to be able to reuse that employee photo for other purposes (who knows what for, just go along with the example :)). But other people shouldn't be allowed to look at this form because it could potentially hold sensitive information. I need to move this photo out of this form and into another, less-restricted library. So I created a 'Team Photos' Picture Library for this purpose. Now, all I have to do is create a workflow to do the photo extraction. I can create a workflow and attach it to my New Hire Forms document library and configure it to start automatically when a new item is added. Then, I can configure my new workflow as follows:

I have three actions here. The first action is my custom extraction action. I configured it to pull the photo from the 'employeePhoto' field using the current item in the New Hire Forms document library. I save this photo to the Team Photos picture library (and instead of specifying a filename, I'll just use the attachment's filename). I will overwrite the picture if it already exists. Finally, I store the id of the newly added item in the Team Photos library to the workflow variable 'new item id'.

The second action is actually an Update List Item action. I use this action to grab the last name of the employee (from the New Hire Forms item) and save it to the description field of the item I just saved in the picture library. That's why saving the id is important because you can use it to reference to later or make cross references to (which I'll get into in a second). The following is the configuration of this action:

Obviously, I could have created a workflow variable that was a concatenation of the first name, last name, department, etc and used that to fill out the description but this is just for demonstration purposes.

Lastly, the third action is again an Update List Item action. With this action, I update the current item I'm executing this workflow against so that I can add a cross-reference to the photo that I just extracted and stored somewhere else. One of the columns in the New Hire Forms document library is a lookup column called Employee Photo. I configured the lookup column to point to the Team Photos picture library with the referencing being the ID of the picture item. Then, I just configured the action in my workflow as follows:

That's it for the workflow. Finally, when it runs, here's what I get:

In my New Hire Forms library, you can see the workflow has finished executing and there is a link under Employee Photo to the photo that was extracted. And here's the Team Photos picture library with the extracted photo:

So, that's pretty much to it. I think from this example, it's easy to see the value of taking some time and really thinking about coming up with custom workflow activities. Custom workflow activities exposed as SharePoinw Designer workflow actions can really enable your users to build their own solutions, possibly in ways you wouldn't have imagined yourself. That's normally how I try to envision solutions. When someone asks me to build something, I ask myself, can I build something else that will allow them to create their own solution now and in the future.

I attached the SharePoint solution file (.wsp) below as well as the VS2008 project files.

In the future, if I see there's enough interest (through comments), I can go into a discussion of the code.

DeviantPointWorkflowActivities.wsp (7.20 kb)   - Once this solution has been deployed, you need to activate the DeviantPoint Custom Workflow Activities web application feature. Repeat - web application feature, not site collection, not site.

DeviantPoint.SharePoint.Workflow.zip (499.49 kb)

I was writing a custom workflow activity for SharePoint Designer today (a pretty cool custom activity, if I do say so myself, which I'll post in a few days) and on my custom activity, one of the settable fields I have happens to be the last word in the sentence:  

So I went to go set the field and this is what I get:

Whenever I went to set the field, the hover action over the activity added a drop down button to the end, thereby making the field impossible to set. Anyways, I'm just going to change the sentence but I thought it was pretty funny and wanted to share it.

While there have plenty of things that people don't like about Windows Vista, one of the features I do like and I think is underappreciated is the new breadcrumb:

Unfortunately in SharePoint, the breadcrumbs don't work like this. There are no submenus. Lucky for us, it's pretty easy to create a breadcrumb that functions this way. Here's how:

Creating the web control

The first part we'll need is a web control that will render the markup. The web control I created is simple and straightforward. Only two public properties are available: SiteMapProvider (string) and NodeSeparator (string). The SiteMapProvider property is used to specify the named site map provider from the web.config file to use to build the breadcrumb. The NodeSeparator property is used to specify the character(s) to use to separate each item in the breadcrumb (like the sideway triangles in the screenshot above). By default, this is set to the '>' character. Also, this property will only be used if the breadcrumb item doesn't have any sub-items; if it does, then a clickable image like the one above will be displayed instead. Lastly, the breadcrumb's submenus will only go one level deep (like Vista's). So there won't be any "submenus of submenus".

The rendering logic takes place in the RenderContents(HtmlTextWriter) method. First, we get an instance of the SiteMapProvider object that has the same name as the one specified in the control's SiteMapProvider property. Then, using the provider, we traverse our way up the site map from the current page (specified by the SiteMapProvider.CurrentNode property) until we get to the top of the site map. While we traverse up, we will collect the nodes that we passed in a Stack<SiteMapNode> collection:

Once we've reached the top, we then pop the nodes out of the stack. Each node will be represented as a list item (li) in an unordered list (ul). If the node has any subitems, then we will render a clickable image and unordered list that is a child of the list item:

This is the typical html markup that is rendered by the breadcrumb control:

That is pretty much it for the web control. The next parts we need to build are the CSS and the JavaScript.

CSS and JavaScript

I won't bore you with the details of the CSS since it's available in the zip file below but the most important things with the CSS are: making sure the breadcrumb items are displayed inline and making sure the submenu uses absolute positioning and has a z-index that will place it on top of any other element that is going to be on the page.

Now for the UI magic to happen, we need a little client-side code. Here again, I use my new favorite client-side library, jQuery. The client script primarily consists of three event handlers: an event handler for the click event on the image, an event handler for a submenu item's hover event, and an event handler used to handle clicks anywhere else on the document.

The click event for the image is used to show/hide the corresponding submenu. It will also make sure that no other menu is visible besides the one that corresponds to the image that was clicked. Finally, it will toggle an appropriate image to use, depending on whether or not the submenu is visible or hidden:

The hover event handler for each submenu item will take care of making sure the item is highlighted properly. The highlighting we will use is the same highlighting used by the top navigation menu:

Lastly, the click event handler for the document will make sure that if the user clicks outside of the breadcrumb, any visible submenu will be hidden:

Putting it all together

So now that we've built the components, it's time to put it all together. First, add the breadcrumb.css file and breadcrumb.js file in a document library or folder in the SharePoint site collection. You also need to place the jQuery javascript library in a document library/folder (note: I used jQuery version 1.2.6 for this).

Second, you need to deploy the assembly 'DeviantPoint.SharePoint.Web.UI.dll' to the Global Assembly Cache (GAC) and then reset IIS.

Third, in order to be able to use the web control we developed, you need to add an entry into the SafeControls section of your web.config file:

Lastly, you need to modify your site collection's master file by first registering our custom assembly:

Then you need to add a reference to the css and javascript files we are using:

Note that in this case, I put 'Breadcrumb.css' in the default Style Library document library. I put the javascript files in a folder I created with SharePoint designer called scripts. Also, make sure to place these lines right before the closing 'head' tag in the master file.

Lastly, we need to place the breadcrumb control in an appropriate spot on the master page where we'd like the breadcrumb to appear:

In this case, I actually replaced the default global breadcrumb that comes out of the box with my own breadcrumb. I also used the GlobalNavSiteMapProvider because that site map provider will have all of the nodes for the site collection.

Results

Here are some screenshots of the new breadcrumb in action:

See? Not too difficult!

Files

In the zip file below, you'll find the assembly that needs to be deployed to the GAC, Breadcrumb.cs, breadcrumb.css, breadcrumb.js, and deviantpoint.master. Deviantpoint.master is just the out of the box master with all the changes to the master file I specified above. You will need to download jQuery v. 1.2.6 yourself.

DeviantPoint_Breadcrumb.zip (11.12 kb)

I had to configure SSO on a MOSS farm with split back-to-back topology with the Web Front Ends (WFEs) in the perimeter network belonging to one domain and SQL Server in the internal network belonging to another domain (there was a trust relationship defined between the two domains). All the service accounts, farm accounts, and database access accounts being used came from the internal domain.

When I tried to configure the SSO service (ssosrv.exe) to use an account from the internal domain, I would get the following error:

A Single Sign-on error has occurred.  Please contact an administrator.  Details: The network path was not found.

There would also be a corresponding entry in the event log like this:

User internaldomain\internaluser failed to configure the single sign-on server. The error returned was 0x80630005. Verify this account has sufficient permissions and try again.

The account used absolutely had sufficient permissions. It met all the criteria specified in http://technet.microsoft.com/en-us/library/cc262932.aspx for the ssosrv.exe service account. I tried and re-tried with other accounts, making the account a domain admin, giving it every SQL Server permission known to man (jk) and it still didn’t work. I even manually created the SSO database myself and ran the SSO schema script myself and manually added permissions to it but I still couldn’t get SSO configured in Central Administration. Actually, I had ruled out issues with SQL Server permissions earlier because when I checked the SQL Server logs, there weren’t even any log entries for login failures. So I sort of came to the conclusion that something else was happening on the WFE before it even got to the database.

After struggling with the configuration for a while and looking at many error log entries, I finally got it configured. Looking at the ULS logs actually helped me resolve the issue because I noticed the following entry:

Net{User|Group}GetInfo said Account {internaluser} does not exist   

What a strange error. Clearly, SSO configuration was attempting to use the command-line command NET USER internaluser to get information about the account being used by ssosrv.exe. But issuing that command goes against the current domain of the machine, which in this case was the domain of the perimeter network and not the internal network domain where this account really came from. By switching the account used by ssosrv.exe to an account that instead came from the perimeter domain and adding that account to SQL Server (and making sure it conformed to the criteria as outlined in the article above), I was able to successfully configure the SSO.

Just another example where the error displayed hardly gets you down the right path.

A client wanted to be able to secure specific items in the Issues list of a Project Workspace site so that only a certain group could view the item. No problem, right? Just use the out of the box item-level permissions functionality in SharePoint.

Not so fast. This works well until you start linking a project task to one of these issues. If a project task is linked to an issue or issues for which a user does not have permissions for, then the user will get the typical Access Denied SharePoint error page when the user tries to view the task's linked issues page. So far, so good. Unfortunately, if the task is linked to multiple issues, some of which the user has permissions to view and some of which the user cannot view, the same Access Denied SharePoint error page will be shown. You would think that the user wouldn't get this error page and instead would get a list of just the items he/she has access to but unfortunately not. Hopefully, this will be fixed in the future by Microsoft.

A few weeks ago, I was doing some code reviews when I ran into the following snippet of code:

Example A

SPWeb web = new SPSite(siteGuid).RootWeb;

I told the developer who wrote the code to dispose of these objects he created per the suggestions in the Best Practices: Using Disposable Windows SharePoint Services Objects article. The next morning, the developer sent me an email pinpointing a piece of code he thought I wrote that to him seemed to be the same type of code as his where the objects weren't being destroyed. This was the piece of code:

Example B

SPWeb web = SPContext.Current.Site.RootWeb;

So what was the deal here? Was this a case of "do as I say, not as I do"? No, it wasn't. First of all, the code he was citing wasn't actually written by me, it had been written by another developer. I was, however, the reviewer. Second, I was concerned not only with the web object in his code but the SPSite object he "news up". Both of those objects need to be destroyed which he wasn't doing. At the very least, Example A code should have been rewritten as:

SPSite site = new SPSite(siteGuid);
SPWeb web = site.RootWeb;
//do stuff
web.Dispose();
site.Dispose();

One thing you'll notice here is that I keep a reference to the SPSite object that is being created. That is because this object will later need to be disposed of and by not keeping a reference to this object, there is no way we would be able to do that.

Now back to the RootWeb object, which this developer was pointing out to me also wasn't being disposed of in Example B code. So why not? Is this bad practice not to dispose of the RootWeb object? If you read the best practices article, it clearly states that the SPSite.RootWeb property creates a new object and assigns this new instance to a local member variable. Each subsequent access will be referencing the object stored in the local member variable. Basically, the RootWeb object is lazy loaded on first access. The article later warns that after you're done using the RootWeb property, you should dispose of it. Clearly, Example B doesn't do that. However, not everything is as straightforward as this article suggests.

In the example code in the article, the RootWeb object being accessed is from an SPSite object that was created explicitly. In Example B above, the RootWeb object is being accessed from the SPContext.Current.Site object. As most of you know, the Site and Web properties from SPContext.Current are special in that the disposal of these objects are managed by SharePoint and should not be disposed of explicitly. So what happens then if you dispose of RootWeb from SPContext.Current.Site? Will you get the dreaded "Trying to use an SPWeb object that has been closed or disposed and is no longer valid" error message you might get if you disposed of the Site or Web objects? No you wouldn't. That's because the getter method of the RootWeb property checks to see if the local member variable web object is null. If it is null, then the root web object will just be created and it will be assigned to a local member variable (the lazy loading described above). When the RootWeb is disposed, the reference is set back to null. So any subsequent calls to the property after RootWeb has been disposed of will just reconstruct the object again. So you could dispose of it if you want. But for performance reasons, my suggestion is you shouldn't.

The particular line of code in Example B is actually inside a method in a class that was created to handle a custom localization solution. Potentially, this method could be called 20-25 times per page request. If the RootWeb.Dispose() method is called within this method, then that would mean we would be creating and destroying the same object 20-25 times per page request. That will affect performance. But if I'm suggesting that you don't explicitly dispose of this object you should be asking yourself if we are then creating a memory leak. The answer is no.

When an SPWeb object is created, a reference to this object is added to an internal list of SPWeb objects maintained in the SPSite object to which the SPWeb object belongs. When the SPSite object is disposed, all SPWeb objects in this internal list (m_openedWebs) are iterated over and have their Dispose() methods called also. Since a reference to the root web is added to this internal list of the SPContext.Current.Site object, even though we don't call the SPContext.Current.Site.RootWeb.Dispose() method explicitly, the RootWeb object will eventually be disposed when SharePoint has finished the request and disposes SPContext.Current.Site for us. By following this suggestion, RootWeb will be created and destroyed only once per page request rather than the 20-25 times it would have been had we called RootWeb.Dispose() explicitly.

If you're interested in developing on the SharePoint platform, these are some of the considerations you need to be aware of. As I mentioned in my previous blog entry, in order to really write good SharePoint code, it is important to know the SharePoint object model's implementation. Otherwise, it is very easy to write inefficient code even while we believe we're following all the guidelines and the best practices.

UPDATE: It looks like the Best Practice document has been updated. It is now NOT RECOMMENDED for you to dispose the RootWeb directly. Looks like they've acknowledged that this is being handled internally, as I mentioned above. This is the text from the MSDN article: 

SPSite.RootWeb Property

An earlier version of this article indicated that the calling application should dispose of the SPSite.RootWeb property just before disposing of the SPSite object that is using it. This is no longer the official guidance. The dispose cleanup is handled automatically by the SharePoint framework. Additionally, SPSite properties LockIssue, Owner, and SecondaryContact used the RootWeb property internally. Given the updated guidance for RootWeb, it is no longer advisable to call the Dispose method on the SPSite.RootWeb property whenever any of these properties are used.