Blog

I came across this great posting from Jie Li while looking around Stefan Goßner’s blog at https://blogs.technet.com/b/stefan_gossner/ and thought it would make interesting reading for the Project audience too.  One word of caution first – Jie Li mentions the well known SharePoint practice of detaching content databases while applying patches so that you can upgrade them at your leisure later – once you have re-attached them.  Project Server databases (Archive, Draft, Published and Reporting) ARE NOT content databases – please do no detach these while patching or you will get into an inconsistent state that may cause you (and then me and my support colleagues) big problems… On to the article – https://blogs.msdn.com/b/opal/archive/2011/06/30/the-mystery-behind-sharepoint-2010-patching.aspx . Enjoy!

  Here’s a list of content that the team has been hard at work on delivering this summer: Published the week of July 11, 2011 Updated article Deploy cumulative updates (Project Server 2010) Updated with information about the June 2011 Cumulative Update. Published the week of June 27, 2011 New articles for Project Server 2010 SP1 Deploy Service Pack 1 for Project Server 2010 Describes how to deploy Microsoft Project Server 2010 with Service Pack 1 (SP1). This article provides an overview of key enhancements, deployment instructions, considerations, known issues, and links to related resources. Updated for Project Server 2010 SP1 Hardware and software requirements (Project Server 2010) , Plan browser support (Project Server 2010) , and Project Server 2010 with SharePoint Server 2010 architecture (overview) Updated to include information about additional supported Web browsers for Microsoft Project Web App Team Member pages in Project Server 2010 with SP1. New articles Database maintenance plans for Project Server 2010 Describes database maintenance recommendations for Project Server 2010. Updated articles Install and configure Project Server 2010 and Plan for deployment (Project Server 2010) Updated to specify that Project Server 2010 is not compatible with multi-tenant environments. Run Migration Script 7 to compare Project Server 2003 and Project Server 2007 data validation snapshots Updated to include information about the script’s possibly reporting a false mismatch of task identifiers between Microsoft Office Project Server 2003 and Microsoft Office Project Server 2007 tasks. Published the week of June 13, 2011 New articles Plan hardware architecture in Project Server 2010 Discusses the recommended hardware configurations for various Project Server 2010 dataset sizes. Upgrade from a trial version of Project Server 2010 Describes how to upgrade your Project Server 2010 trial version to the fully licensed version. Published the week of June 6, 2011 New resource center Enterprise Project Management (EPM) Content Pivot Viewer Use the pivot viewer to browse a complete collection of articles, white papers, training videos, and models for EPM in Project Server 2010. Pivot on content by lifecycle, solution area, or content type.

This posting follows on from the one yesterday concerning how Project Server makes use of SharePoint permissions and features – but concentrates on some potential issues you can run into if you have a very large user base and also have projects that have very large teams.  We are also authoring a TechNet article explaining this in more depth – I will add a link once it is published.  This isn’t going in to the usage of the RBS or the other internal feature – but concentrates more on the technical issues of large user populations.  If you fit in this category then read on… As mentioned in the previous post Project Server 2010 uses the normal SharePoint permissions infrastructure to set access control both to the Project Web App (PWA) site and also any Project sites that are created for the individual project plans held in Project Server.  At the PWA site level the users are added to certain groups depending on their permissions levels within Project Server, so you will generally see SharePoint groups for Project Managers, Readers, Team members, Web Administrators and finally Workflow and Project Detail Pages Administrators.  Each of these groups will show the individual PWA users as appropriate.  This is a change from 2007 where individuals were added to the PWA site with specific permission levels.  You may have seen issues in 2007 if you had large numbers of users as whenever changes were needed in the member permissions the users would be removed and then added back – so some users would get “Access Denied” until they were added back after a change.  We had some workarounds for this scenario involving turning off the user synchronization.  In 2010 we made a couple of changes to avoid this problem – firstly the change to using groups at the PWA site level, and secondly we now remove then add back each individual as opposed to removing everyone and then adding back everyone.  So getting an Access Denied in the same scenario in 2010 is very unlikely. At the Project site level however we do not use the group approach and manage the users on an individual basis.  In most scenarios this is not an issue as the number of resources assigned to a project, and hence added to a site, is generally low compared to the total number of users in the system.  However there could be some scenarios where customers wish to have many or all of their users accessing many or all of their project sites.  This could either be achieved by adding many users to a project – or by giving the “View Project Site” permission at the team member level in a category that included many or all projects.  Either way this would then add very many individual users with permissions to the project sites.  And why is this a problem?  If the numbers of users is large then it is possible for the recommended software boundaries and limits of SharePoint Server to be exceeded – and this can lead to performance issues.  Each user added individually to a site would be considered a security scope – and the recommended maximum number of unique security scopes per list is 1,000 (SharePoint Server 2010 capacity management – Software boundaries and limits – https://technet.microsoft.com/en-us/library/cc262787.aspx ).  So each list and library in the site would be inheriting from the parent site permissions – and would exceed this limit if more than 1,000 user had access to the site (as they are individually added). In our experience the performance issues would then relate to any change in the site membership caused by changes in the categories or groups – or following such actions as adding a user or inactivating a user.  For example this last action of inactivating a user will actually remove that user from all sites they have access to – and the reason the limit is imposed is that when it is exceeded the process of removing a user can become very slow – particularly if this same user is also being removed from very many sites each of which is also way over the limit.  In extreme cases with multiple user inactivations it is possible that the server will become unresponsive and unable to authenticate users. I will include some of the error messages you might see, and the corresponding ULS entries at the end of this posting so that this aids finding this potential cause. If you are following along (and I’m sure some of my readers are way ahead of me…) you will realize there is a Catch-22 here.  Your server could become unresponsive whenever you need to manage users because you have too many users with permissions on the sites.  So remove some users… which will then make the server unresponsive…  How to escape from this loop?  There are some quick ways to get this resolved – but before rushing in to that it is better to review what it is you are really trying to achieve.  If the desire is that most people can access most projects then managing the permissions outside of Project Server using groups and inheritance from PWA is the way to go.  If however the fact that many users had access to many sites was really a mistake then you need to correct that issue – and either remove the “View Project Sites” from the offending category or reduce the number of resources assigned to the plans – but first of course you need to stop the synchronization of users to the sites otherwise any action may make your server very slow.  As mentioned in the previous post this can be achieved by us of the UserSyncSettings method – and just repeating that here to save you having to open that post up: The setting can be changed using the PSI and the Admin Web Service and the UserSyncSettings method. The enumeration of values that can be set are detailed at https://msdn.microsoft.com/en-us/library/websvcadmin.usersyncsettings_di_pj14mref.aspx , and the method described at https://msdn.microsoft.com/en-us/library/gg229480.aspx . Turning off the Project Site sync is achieved by the enumeration DisablePWS.   Member name Description Enabled Value=1. Enable all synchronizations. DisablePWA Value=2. Disable synchronization with Project Web App. DisablePWS Value=4. Disable synchronization with project sites for the user. DisableEmailSync Value=8. Disable email synchronization. DisableAll Value=16. Disable all synchronizations. This relates to settings in the MSP_WEB_ADMIN table of the Published database in the WADMIN_USER_SYNC_SETTING column. So for example a query such as: Update [ProjectServer_Published].[dbo].[msp_web_admin] set [WADMIN_USER_SYNC_SETTING] =4 would do the same as using the method to set the enumeration: int syncSettings = (int)SvcAdmin.UserSyncSettings.DisablePWS; We’d certainly prefer you to not touch the DB correctly – but I’m guessing that many of you would find it much easier to execute a SQL query to update the value than to write the code necessary to do the same (I certainly would!). Once that is turned off then you can safely do user management without causing further performance problems – but of course it would still be possible to trigger the same issues if you tried removing the users directly from the project site, using the out of the box SharePoint functionality. One way to remove the users very quickly without triggering the individual deletion that causes the problem is to inherit permissions from the parent.  This can be done via the UI on the Site Actions, Site Permissions page of the individual sites: This will lose any custom permissions.  If your end goal is to give most users access to most sites then this may be how you want to keep things long term – so before taking this action you would probably want to be sure that the PWA site has the right permissions for all the users who need access – as that will be where this site will start inheriting from once you click the button.  Obviously if you have thousands of sites (and you probably have if this is causing you problems) then PowerShell can automate the change for you. Run the following PowerShell command in the SharePoint 2010 Management Shell $site = Get-SPSite “ ” Foreach ($web in $site.AllWebs) {
        $web.Update()         $web.ResetRoleInheritance()         $web.Update()         } $site.Dispose() This (or the UI method) would also need to be run for any new sites created to avoid the problem coming back – but if you had ‘corrected’ your categories and team memberships then all would be ok going forward. If you do decide that leaving everything inheriting is right for most projects then you may also want to have certain projects that are more ‘secret’ and for these you will need to continue to manage the permissions and user on an individual level.  One thought I had was to set a property on these ‘special’ sites via PowerShell and then you could use this property to filter out in a modified version of the above PowerShell command and ensure you didn’t reset the role inheritance accidentally.  I should also point out that if you use the Synchronize option on the Project Sites page then this would re-break the inheritance – so should be avoided. As a guide we have seen the issue with a customer with around 3000 users where they are nearly all added to each of their 1500 sites.  And as promised, here are the error messages and ULS entries.  Different users may see different symptoms – but the user who initiates the issue, perhaps by inactivating a couple of resources, will see the ‘Save’ button on the page apparently stick on the ‘clicked’ position and eventually get a “An unexpected error has occurred.” message.  The correlation ID will be found in the ULS logs and will have several rows all relating to a SQL deadlock and the Critical level one will look like: 08/10/2011 12:17:02.85    w3wp.exe (0x2178)    0x314C    SharePoint Foundation    Database    5586    Critical    Unknown SQL Exception 1205 occurred. Additional error information from SQL Server is included below.  Transaction (Process ID 80) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.    886d9cdd-5c0c-4f3a-8f89-f4e8c92acde3 Another High level one that gives more information on the query causing the issue will be something like: 08/10/2011 12:17:06.97    w3wp.exe (0x2178)    0x314C    SharePoint Foundation    Database    tzkv    High    SqlCommand: ‘SET NOCOUNT ON; DECLARE @DN nvarchar(256),@LN nvarchar(128),@@DocUIVersion int,@@S uniqueidentifier,@@Level tinyint; DECLARE @ItemId int; DECLARE @@iRet int; DECLARE @ExtraItemSize int; SET @@Level = 1; SET @@S=@wssp0;  EXEC @@iRet = proc_SecRemoveUserFromSite @@S, @wssp1, @wssp2  SELECT @ItemId = @wssp3  IF @@iRet 0 BEGIN  GOTO DONE; END  ;BEGIN TRAN IF NOT EXISTS( SELECT tp_ID FROM UserData WHERE tp_ListId = ’06C8C9BB-B10B-4042-8859-9F9985E73E76’ AND tp_ID = @ItemId  AND tp_Level = 1 AND tp_RowOrdinal =0) BEGIN  SELECT @ExtraItemSize = 0  EXEC @@iRet = proc_AddListItem @SiteId…. I have shortened it considerably – but the key piece is the proc_SecRemoveUserFromSite.  Finally the ‘Unexpected’ one: 08/10/2011 12:17:06.97    w3wp.exe (0x2178)    0x314C    SharePoint Foundation    Runtime    tkau    Unexpected    System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80131904    at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateMembers(String bstrUrl, UInt32 dwObjectType, String bstrObjId, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bRemoveFromCurrentScopeOnly, Boolean bSendEmail)     at Microsoft.SharePoint.Library.SPRequest.UpdateMembers(String bstrUrl, UInt32 dwObjectType, String bstrObjId, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bRemoveFromCurrentScopeOnly, Boolean bSendEmail)    886d9cdd-5c0c-4f3a-8f89-f4e8c92acde3 Once the sever is in the condition – which could last 15-30 minutes, then other users will get timeouts on their pages and the ULS logs may show the following: 08/10/2011 12:20:22.30    w3wp.exe (0x1228)    0x1454    SharePoint Foundation    Monitoring    b4ly    High    Leaving Monitored Scope (ExecuteStoredProcedureDataReader — MSP_AUTH_GETUSERBYNAME). Execution Time=120002.728838442    2be0491a-a64b-4237-8cfc-40342a374d49 08/10/2011 12:20:22.30    w3wp.exe (0x1228)    0x1454    Project Server    General    8ym5    Monitorable    PWA:https:// /PWA, ServiceApp:Project Web App Service Application, User:, PSI: SqlException occurred in DAL:  0 0 -2     System.Data.SqlClient.SqlError: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.         at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)     at … I should also point out that use of the Project Site Provisioning Settings page option to not automatically synchronize users may avoid you getting in to this situation – but you still need some process to control access – and if most sites are unrestricted then the inheritance option from PWA may be worth a try.  Just as a reminder – the option on the Project Site Provisioning Settings page looks like this: and un-checking will stop the automatic addition of Project Server users to sites (but will not remove ones who are already there). Hopefully the workarounds given will assist in avoiding these types of issues if you really need to have very large numbers of users accessing each of a large number of project sites. As promised – once we have a TechNet article out in the wild I will link to it.

In Project Server 2010, and in 2007 too for that matter, Project Server manages the setting of permissions on the various SharePoint sites used for Project Server.  So for example when you add a user to Project Web App (PWA) they will also be added with the right permissions to the PWA site itself.  If you then add them to a project then depending on your settings they would also get added to the SharePoint site for that specific project plan – enabling them to use the Issues, Risks and document features. This can lead to potential issues depending on how you have configured Project Server, how many users you have and also which features of SharePoint you are using.  This post deals with the last point, but I will be publishing another post shortly that deals with the other issues you can come across – particularly what can happen if you have very many users with access to very many projects, and hence access to very many sites. But first – alerts and notifications.  We had a customer who found that they could set notifications on a list on a project site through a subscription, so that they could get notified of any additions, changes etc.  However, they noticed that they were not getting the notifications they expected and when they examined the list again the subscription was gone!  It transpired that the method Project Server uses to keep the user list in sync (the various settings within groups and categories – and team changes within a plan) was breaking this feature.  Basically we remove and then add back the users ensuring they have the correct permissions – but unfortunately in the process we lose any subscriptions they may have to be notified of changes in the list! So if this is a feature you are using and wondering why it keeps breaking – or perhaps it is a feature you would like to use – then it may be best to disable the synchronization with the project sites to avoid this problem.  This would of course mean that you would then need to manually keep control of the user permissions on the sites.  If you go this route then I would also suggest that adding users to groups rather than individually is the best way to go.  More on that in a future post… The setting can be changed using the PSI and the Admin Web Service and the UserSyncSettings method.  The enumeration of values that can be set are detailed at https://msdn.microsoft.com/en-us/library/websvcadmin.usersyncsettings_di_pj14mref.aspx , and the method described at https://msdn.microsoft.com/en-us/library/gg229480.aspx . Turning off the Project Site sync is achieved by the enumeration DisablePWS. Member name Description Enabled Value=1. Enable all synchronizations. DisablePWA Value=2. Disable synchronization with Project Web App. DisablePWS Value=4. Disable synchronization with project sites for the user. DisableEmailSync Value=8. Disable email synchronization. DisableAll Value=16. Disable all synchronizations. This relates to settings in the MSP_WEB_ADMIN table of the Published database in the WADMIN_USER_SYNC_SETTING column.  So for example a query such as: Update [ProjectServer_Published].[dbo].[msp_web_admin] set [WADMIN_USER_SYNC_SETTING] =4 would do the same as using the method to set the enumeration: int syncSettings =  (int)SvcAdmin.UserSyncSettings.DisablePWS; We’d certainly prefer you to not touch the DB correctly – but I’m guessing that many of you would find it much easier to execute a SQL query to update the value than to write the code necessary to do the same (I certainly would!).  Wouldn’t it be nice if we could do it via PowerShell?  That is something I am looking into – and the Admin web service is an ideal candidate to be wrapped up like the Project and Security web services have been at https://archive.msdn.microsoft.com/pj14PowershellPSI by Mike Shughrue. As mentioned I will be following this up with another post with some other considerations around turning off the automatic sync particularly if you have large numbers of users who each have access to large numbers of sites.

As announced by Jan last week, we will have a dedicated Project/Project Server pre-event ahead of SharePoint Conference 2011 on Sunday October, 2nd, 2011 : SharePoint Partners – Interested in growing your business with Project 2010? A great opportunity for SharePoint/non Project Portfolio Managers to learn about our stack. More info here . There will also be plenty of Project sessions during SPC11 so don’t wait and register, looking forward to see you in California in early October:

Almost all Project Server administrators know that when you have an enterprise custom field using a lookup table that you can pick one of the values from that lookup table to be the default value for new entities.   But what about a case where the field is set to NOT have a default value but some new projects are being created where when the Save button is hit on the New Project PDP a value is being entered for that field? What might cause that? There are (at least) two possible answers. Templates on Enterprise Project Types When you create your enterprise project types you can associate an enterprise project template so that when a new project is created using an EPT it will automatically use that template. It is possible for a template to contain values in some enterprise fields as part of the template. If the template associated with the EPT has a value in that custom field then it can look like there was a default value set for the field, even when the field itself does not have a default set. Two things lead to this being overlooked: EPTs are a new feature to Project Server 2010 and it does not always occur to users that clicking “New” in the Project Center could call up a template to begin with. Many organizations tend to strip out custom field values when saving a project as a template so the idea of there being a value in the fields for a template might not occur to everyone. I have seen this issue at 2 different locations now and it can cause some pretty severe head-scratching.   Workflow Code or Custom Event Handler Code Through workflow coding or custom event handler code there could be situations where the code would examine the values of certain custom fields when the project is initially saved and then make decisions about the values of other custom fields. An example of this is if a project is created and the user picks “Washington” as the value for the ‘Location’ field. The code might be set to assign a certain value for an Account Manager” field based on the project being located in Washington state. For some users that do not know about this coding it might appear as if there were default values on some fields. This type of coding is much more common now in 2010 and in most cases users and certainly the administrators are likely to know about these kinds of changes. In my experience the most common cause for confusion about mystery ‘default’ values is going to be from a template on an EPT.

While we realize that many BPOS customers are eager to move onto the new Office 365 service and start using all the new features, we strongly recommend that you wait until we are ready to transition your tenant for you. We have received a number of Support calls from customers and partners who have tried to migrate their data from BPOS to Office 365 by themselves. Please be aware that if you attempt a manual migration, emails sent to your domains will be returned to sender as undeliverable until Support can delete your domain from BPOS and you can re-create in Office 365. This email outage could last as long as 24 hours (possibly longer if many customers are asking Support to delete their domains at the same time as you). What should someone do who is eager to move from BPOS to Office 365? Ideally, you would wait to be transitioned by the Office 365 team. However, if you are an expert in Exchange server migrations, comfortable with PowerShell scripts, and just can’t wait a couple of months, here’s what you need to do. (Please note that manual migration is not supported, manual migration will stop mail flow for at least 24 hours, and customers with Exchange Hosted Archiving will lose all archived data). Ensure all of your computers meet the Office 365 system requirements. Sign up for an Office 365 account. Do NOT add any other domains at this point Run the Office 365 online desktop setup tool on all desktop PCs. Back up all of your users’ mail to .pst files using Outlook. Remove all vanity domain information from BPOS. Remove all production domain e-mail addresses from any accounts using them. Here’s an example. Your production domain is contoso.com. You have a user, Joe, with the e-mail addresses Joe@contoso.microsoftonline.com and Joe@contoso.com. Remove the Joe@contoso.com e-mail address, as well as any other e-mail addresses in the system that end with contoso.com. Remove your production domain from BPOS. Contact BPOS Support, and Tell them you wish to have your production domain removed from FOPE. Ask them to check in the Office 365 environment to see if Microsoft has already copied your domain(s) and users to a pre-transition tenant. If this has happened, your domain(s) will need to be removed from Office 365 as well Wait 1 day for Support to remove your domains. You will receive no inbound email for this period. Sign in to your Office 365 admin account and add your production domain to Office 365. Add your users to Office 365. Import the .pst files you made in step 3 into the appropriate user mailboxes using Outlook. There will be a feature allowing domains to be deleted in FOPE without a call to Support, but it will take some time before this option is available. Please keep an eye on this blog for further updates. Final note: I have personally seen some creative workarounds in the BPOS community to the email outage that inevitably occurs while FOPE is deleting your domain. They’re not perfect, and Microsoft doesn’t support them (nor have we tested them).

Now that Office 365 has launched, we’re preparing to start transitions in September 2011, and we’ve updated the Transition Guide and Transition FAQ to provide you more information about what to expect between now and September 2012. Here’s a summary of the key actions you should take. 1)   Review the transition guide. This comprehensive overview covers all aspects of the transition process. Download the transition guide for in-depth information on everything from system requirements to the specific steps required for administrators and current users. 2)   Learn the key changes. Some of these system requirements may require you to upgrade your PCs before you transition. Make sure your business is ready for Office 365 and the new Microsoft Online Services by noting the following key changes: Outlook 2003 / Office 2003 is not supported Internet Explorer 6 is not supported Office Communicator 2007 R2 must be upgraded to Microsoft Lync Office 365 Desktop Setup is required (replaces the Sign-In Application) Review all of the Office 365 and Microsoft Online Services system requirements . In addition, make sure all your desktops are up to date for the necessary end-user requirements. You can find this information in the transition checklist for administrators. 3)   Understand the Office 365 password policy To make the transition to Office 365 as seamless as possible for your users, we will synchronize their current passwords with Office 365 whenever they change their password. This means that the new Office 365 password policy now applies to your existing subscription. Review the Office 365 password requirements to understand the changes. 4)   Download the transition checklist Start your transition prerequisites – The tasks required to configure your desktop environment can be found in the detailed transition checklist for administrators . 5)   Check out your new subscription offer The following table summarizes how Microsoft Online Services and BPOS subscriptions will map to the new Microsoft Online Services offerings after transition. All active subscriptions will be transitioned to the new offers while maintaining your current price through the end of your subscription term.  Learn more at the Office 365 website . Current Microsoft Online Services  Subscription   New Office 365 or Microsoft Online Services subscription BPOS Standard Suite >   Office 365 (Plan E1) BPOS Deskless Worker Suite >   Office 365 (Plan K1) Exchange Online >   Exchange Online (Plan 1) Exchange Online Deskless Worker >   Exchange Online Kiosk SharePoint Online >   SharePoint Online (Plan 1) SharePoint Online Deskless Worker >   SharePoint Kiosk (K1) Live Meeting Standard >   Lync Online (Plan 2) Office Communications Online >   Lync Online (Plan 1) What happens next? Microsoft will begin contacting customers and partners this summer with September and October 2011 transition dates. Each month, we’ll send out more transition scheduling notices. For more information about scheduling, please check out the transition FAQ . Processing timeframe The transition schedule is designed to best accommodate all customers and their needs, and that could mean your transition won’t be scheduled for several months. Don’t worry if you don’t receive a transition date immediately. Stay up to date 
 The transition center is the place to learn anything and everything about the transition process and all that Office 365 can do for your business. Microsoft Online Services is ready to support you through a smooth transition to Office 365. If you have questions, contact our IT-level support , which is available 24 hours a day, 7 days a week. Also, be sure to take a look at the transition forum – the answers you need are likely already available.

Microsoft is updating the Microsoft Online Services Transporter Tools (aka Microsoft Online Services Migration Tools), adding commandlets to allow Administrators to manage password expiration for user accounts, permissions for Exchange Online mailboxes, and server-side forwarding rules for Exchange Online. The following commandlets are included as part of this update: Set-MSOnlineUserPasswordNeverExpire . This commandlet allows Administrators to set user account passwords to never expire. While Microsoft does not recommend non-expiring passwords due to security best practices, non-expiring passwords are often needed for service accounts that support line of business applications, unmonitored mailboxes, and mail-enabled hardware. Administrators setting non-expiring passwords for user accounts in their organization will need to be aware of actions required when the organization transitions from BPOS-Standard to Office 365. Required steps for organizations with non-expiring passwords can be found in an earlier post to this blog on the topic. Add-MSOnlineMailPermission . With this commandlet, Administrators can establish alternate permissions for an Exchange Online mailbox, such as granting full access to a delegate or granting send-as and send-on-behalf permissions to a delegate. Set-MSOnlineAlternateRecipient . This commandlet allows Administrators to set server-side rules to forward Exchange Online messages to an alternative e-mail address, including forwarding to a distribution list (DL). The updated Transporter Tool supporting these PowerShell commandlets are now available via the Microsoft Download Center .

When: Thursday, September 01, 2011 at 9:30 AM – Friday, September 02, 2011 at 5:00 PM (GMT) Where: Technology House Shottery Brook Office Park Timothy’s Bridge Road CV37 9NR Stratford Upon Avon United Kingdom Hosted By: Technology Associates International Limited Technology Associates International Limited is one of the leading global project management consultancies specialising in Microsoft Office Project and Enterprise Project Management Solutions. Since 1990, Technology Associates have provided deployment, consultancy, development and training services to more than 500 organisations including some of the world’s leading companies, and we have an international presence throughout the world.     Technology Associates have deployed hundreds of EPM solutions and deployed more than 2,000 Microsoft Project solutions. With ten Microsoft Competencies under our belt, including ISV status, we have built a solid reputation for delivering high quality services and solutions, and providing exceptional value for money. Headquartered in the United Kingdom, with Offices in New York, San Francisco, India and Barcelona, and a strategic partner network covering AsiaPac, Middle East and ROW, we work internationally in delivering EPM and SharePoint solutions to our customer base in over 39 countries. Register for this event now at: https://taips2010admin010911-rss.eventbrite.com Event Details: Course Description: This course is designed to cover all the features and aspects of Project Server 2010 Administration. Attendance on the Introductory Project Professional 2010 course is an essential pre-requisite. Attendance on an advanced course with at least two to six weeks as a consolidation period is highly desirable . A ttendees ideally will have some experi ence of SQL Server, IIS, and SharePoint Server . Knowledge of network permissions, active directory and security models would be an advantage. Who Should Attend: Users who have a good knowledge of Microsoft Project 2010 and will be responsible for managing, maintaining and updating the Project 2010 Server database and user information. Course Content: Upon completion of the course, delegates will be able to: Understand EPM 2010 Administration Concepts & Setup ·          Understand the different areas of the PWA Home page and links from it. ·          Understand authentication – types and logins. ·          Understand how to set up e-mail notifications for users and their teams. ·          Demonstrate how to save Microsoft Project information offline. ·          Demonstrate how to view, edit, and update projects & tasks ·          Understand how to reject, create, and delegate task assignments. ·          Understand how to link documents , issues, risks and documents to tasks. ·          Describe the Outlook integration. ·          Show how to view projects in the Project Center & how to create and maintain the views. ·          Show how to view resources in the Resource Center & how to create the views. ·          Demonstrate how to view resource and assignment data related to one or more projects. ·          Understand how to edit enterprise resource information. ·          Describe how to revi ew an archive of object data. ·          View and update task changes to a Microsoft Project plan. ·          View and update calend ar changes. ·          Set up rules to automatically update projects. ·          View a historical archive of task updates. ·          Understand Check In/Check Out of Projects and resources. ·          Understand Outlook integration. ·          Understand Categories/Groups/Permissions & Security Templates and how to use these to configure the system. Essential for analyzing the business and how EPM can be adopted. ·          Understand how d ata is stored in Project Server Databases and in SharePoint. Project 2010 Server Administration ·          Understand the different Administration options. ·          Understand the communication and messaging process. ·          Understand the Task Views, Time Periods, Fiscal Periods and options. ·          Describe the provisioning process for creating workspaces. ·          Understand how to view and upload documents for projects and public documents. ·          Demonstrate searching of documents in the document libraries. ·          Understand how to create and edit an issue or risk. ·          Understand how to customize Issue and risk fields and views. ·          Describe what Microsoft Project Server is and what it is used for. ·          Demonstrate connecting Microsoft Project to Microsoft Project Server. ·          Understand the functionality of Microsoft Project Server. ·          Understand the different user types and the how they interact with Microsoft Project Server and the functionality of each, as well as how to modify permissions. ·          Understand the responsibilities of a Microsoft Project Server Administrator and adopt best practices. ·          Discuss the various views available, their purpose and how to customize them. ·          Understand the integration of SharePoint fr om the Microsoft administration perspective. ·          Understand the Databases in Project Server and how they interact. ·          Understand Reporting and Business Intelligence capabilities in EPM 2010. ·          Understand the Dashboard capability. ·          Understand customization of the Microsoft Project Web Access Client. ·          Describe license manag ement within Project Server 2010 ·          Discuss maintenance of clean data in the Microsoft Project Server database. ·          Understand how security works within Microsoft Project Server. ·          Demonstrate the process for setting permissions. ·          Under stand the process for time track ing and progressing updates. ·          Understand and edit the Resource Breakdown Structure. ·          Understand the Administration options in Project Server and how to use them. ·          Demonstrate and understand the significance of Outline code fields at Project, Task and Resource level. ·          Understand and apply the Portfolio capabilities and administer the settings in Project Server. ·          Understand ULS, Messaging logs, and the Queue services in Project Server. ·          Describe, understand and be able to apply Multi-value fields. ·          Recognise what the Active Cache is and how it works . ·          Understand the concept of web parts and SharePoint as a platform for Project Server.