Have you seen the good news?  Skype and Messenger are coming together.  Soon millions of Messenger users will be able to reach their Messenger friends on Skype.  By updating to Skype, Messenger users can instant message and video call their Messenger friends plus a whole lot more.  Skype will become the preferred choice for all of our users’  communication needs.  We will retire Messenger in all countries worldwide in the first quarter of 2013, with the exception of mainland China.   Learn more about this exciting change . …( read more )

Introduction Apps for Office present a great new opportunity to bring data from a variety of sources into Office applications. The new Project specifically offers a very powerful way to surface both SharePoint and Project Web App data in a task pane app in Project Professional. To connect with SharePoint or PWA from the client, we use on-the-fly OAuth flow as presented in the SharePoint 2013 SDK . The App for Project described in this article connects with the same PWA site collection that Project Professional is currently connected to, and displays data about the currently selected task that is not otherwise available from within Project Professional. This will work with all versions of Project Professional (C2R, MSI, On Demand) and with all PWA environments (Project Online, Project Server). Setup Prerequisites for this project are: Visual Studio 2012 IIS or IIS Express configured to allow applications to run on your server (at localhost) Office 2013 and SharePoint 2013 tools for Visual Studio, available here Project Professional 2013 Project Online tenant or Project Server The first step is to launch Visual Studio 2012. Create a new App for Office 2013 project as shown below. Let’s call it “TaskLastModifiedApp”. In the next dialog, make this a Task Pane App for Project. We need to add references, as this app will use a number of APIs across Office and SharePoint. These DLLs may be in a different location on your system. Most of these references are automatically added if you use the App for SharePoint template, so if you can’t find these on your system, create a quick App for SharePoint solution and note the reference paths to help you out. You should add: C:Program FilesReference AssembliesMicrosoftWindows Identity Foundationv3.5Microsoft.IdentityModel.dll C:WindowsMicrosoft.NETassemblyGAC_MSILMicrosoft.IdentityModel.Extensionsv4.0_2.0.0.0__69c3241e6f0468caMicrosoft.IdentityModel.Extensions.dll C:Program FilesReference AssembliesMicrosoftWindows Identity Foundationv3.5Microsoft.IdentityModel.WindowsTokenService.dll C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15ISAPIMicrosoft.ProjectServer.Client.dll C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15ISAPIMicrosoft.SharePoint.Client.dll C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15ISAPIMicrosoft.SharePoint.Client.Runtime.dll C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.0System.IdentityModel.dll C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.0System.IdentityModel.Selectors.dll C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.0System.ServiceModel.dll Additionally, you will need to add a copy of TokenHelper.cs, which is generated when creating an autohosted or provider-hosted App for SharePoint project. Task Pane App Manifest The actual task pane app is just an XML manifest. Open up TaskLastModifiedApp.xml from the TaskLastModifiedApp project in your Solution Explorer. Replace its contents with the following: 1: 2: 3: [leave this line alone] 4: 1.0 5: Microsoft 6: en-US 7: 8: 9: 10: https: //localhost:44301/ 11: 12: 13: 14: 15: 16: 17: 18: ReadWriteDocument 19: Replace the port after localhost (in both instances) with whatever port you have configured IIS to use for SSL. Make sure to toggle the “SSL Enabled” property on the TaskLastModifiedAppWeb project to true. Let whatever ID was originally set in the manifest remain. Architecture Next, delete the TaskLastModifiedApp.html page – we will need .aspx pages in this project. The basic architecture of the task pane app is as follows: When the task pane app is launched, it loads “URLConstructor.aspx”, which pulls the PWA URL from the client and constructs a call to OAuthAuthorize with the proper tokens to request permissions for the app to access PWA data. This page loads “URLConstructor.js” to interact with the client. OAuthAuthorize is launched in a new window, since we cannot predict the customer’s Project domain. After the user trusts the app, that new window is redirected to “PostOAuth.aspx”, which surfaces the auth code back to URLConstructor.aspx. Once URLConstructor.aspx has the auth code, the task pane app is redirected with this as a token to “Default.aspx”, which has the functional code for the app. This page uses Project CSOM code in its code-behind page to read data from PWA, as well as “TaskLastModifiedApp.js” to interact with the client. Constructing the OAuthAuthorize URL The complete code for URLConstructor.aspx is as follows: 1: 2:   3: 4:   5: 6:   7: 8: TaskLastModifiedApp 9: 10: 11: 12: 13: 14: function getClientId() { 15: var clientId = ‘ ‘ ; //read the clientID from web.config 16: getPwaUrl(clientId); //return to client code 17: } 18: 19:   20: 21: Redirecting… 22: 23:   24: This page needs to be an .aspx page in order to read from web.config, but does not need anything in its code-behind. The clientId read from web.config is needed for the authorization flow. getPwaUrl() is a function within URLConstructor.js. The complete code for URLConstructor.js is as follows: 1: var _projDoc; 2: var pwaUrl; 3: var oAuthUrl; 4:   5: Office.initialize = function (reason) { 6: _projDoc = Office.context.document; 7: getClientId(); //on document load, reads the ClientId from web.config first since it is server-side 8: } 9:   10: function getPwaUrl(clientId) { //uses Office App API to read PWA URL 11: _projDoc.getProjectFieldAsync(Office.ProjectProjectFields.ProjectServerUrl, 12: function (asyncResult) { 13: if (asyncResult.status == Office.AsyncResultStatus.Succeeded) { 14: pwaUrl = asyncResult. value .fieldValue; 15: generateUrl(clientId); //creates the OAuthAuthorize URL with necessary parameters 16: } 17: else { 18: logMethodError( “getProjectFieldAsync” , asyncResult.error.name, asyncResult.error.message); 19: } 20: } 21: ) 22: }; 23:   24: function generateUrl(clientId) { 25: oAuthUrl = pwaUrl + “/_layouts/15/OAuthAuthorize.aspx?IsDlg=1&client_id=” + clientId + “&scope=Projects.Read&response_type=code&redirect_uri=https://localhost:44301/pages/PostOAuth.aspx” ; 26: authWindow = window.open(oAuthUrl); 27: codeListener(); //start listening for the auth code 28: } 29:   30: function codeListener() { 31: setTimeout(function () { readCode(); }, 1000); //check for the auth code every one second 32: } 33:   34: function readCode() { 35: try { //if we can actually reach the authCode field on PostOAuth.aspx 36: authCode = authWindow.document.getElementById( “authCode” ). value ; //pull the authCode value 37: if (authCode != “NA” ) { //if it is not the default “NA” 38: authWindow.close(); //close the new window 39: document.location.href = “/Pages/Default.aspx?code=” + authCode; //redirect task pane to the app code with the authCode token 40: } 41: } 42: catch (e) { 43: codeListener(); //if we couldn’t reach PostOAuth.aspx, wait another second and try again 44: } 45: } When the task pane app loads, it first reads web.config from the aspx page, since this is server-side code. Once it has the clientId, we read the PWA URL. We then create the full OAuthAuthorize URL with the parameters specified above. scope=Projects.Read requests read permission to projects on the current PWA site. Make sure to match the SSL port here as well, as before. On running the app, a new window will open up outside of Project that prompts the user to login to PWA (if they have not checked “Keep me signed in” previously). They will then be presented with a “Do you trust…” page, the same as if they were installing an App for SharePoint. This is the OAuthAuthorize.aspx page. Once trusted, that new window navigates to PostOAuth.aspx, presented below: 1: 2:   3: 4:   5: 6: 7: 8: 9: 10: 11: 12: 13: Closing… 14: 15: 16: 17: And PostOAuth.aspx.cs: 1: using System; 2: using System.Collections.Generic; 3: using System.Linq; 4: using System.Web; 5: using System.Web.UI; 6: using System.Web.UI.WebControls; 7:   8: namespace TaskLastModifiedAppWeb.Pages 9: { 10: public partial class PostOAuth : System.Web.UI.Page 11: { 12: protected void Page_Load( ob
ject sender, EventArgs e) 13: { 14: var code = Request.QueryString[ “code” ]; 15: authCode.Value = code; 16: } 17: } 18: } This page saves the auth code token in a hidden field. The task pane app, still on URLConstructor.aspx, waits for this value and then closes the new window. The app then continues on to default.aspx with the proper code token needed to finish the OAuth flow. Reading the Last Modified Date of the Selected Task The remainder of this article is an example of what you might do in your task pane app now that you have read access to PWA data. This example will show you the Last Modified date and time of the task you have selected. On launch, it shows you data for the selected task, and as you change tasks, the data is updated using an event handler. The complete code for Default.aspx is as follows: 1: 2:   3: 4:   5: 6: 7: TaskLastModifiedApp 8: 9: 10: 11: 12: 13: 14:   15: 16: 17: 18: 19: 20: 21:   22: 23:   24: 25: 26: 27:   28: 29:   30: 31: This page contains three hidden fields used to pass data back and forth between the client-side code and the server-side code. It also leverages a label to surface the results to the user, and a hidden button that the client-side code uses to call a server-side function, as you will see below. The complete code for TaskLastModifiedApp.js is as follows: 1: var _projDoc; 2: var taskGuid; 3: var projGuid; 4: var pwaUrl; 5:   6: // This runs after every postback 7: Office.initialize = function (reason) { 8: _projDoc = Office.context.document; 9: if (document.getElementById( “pwaUrlHF” ). value == “NA” ) { //if this is the first run 10: firstRun(); 11: } 12: manageTaskEventHandler( ‘addHandlerAsync’ ); //need to re-register event handler after each postback 13: } 14:   15: // Only need these on the first page load, not on postbacks 16: function firstRun() { 17: getProjGuid(); 18: _projDoc.getProjectFieldAsync(Office.ProjectProjectFields.ProjectServerUrl, 19: function (asyncResult) { 20: pwaUrl = asyncResult. value .fieldValue; 21: document.getElementById( “pwaUrlHF” ). value = pwaUrl; 22: } 23: ) 24: getTaskGuid(); 25: } 26:   27: // Get the GUID of the selected task, comes from SDK 28: function getTaskGuid() { 29: var TaskLastModLabel = document.getElementById( “TaskLastModLabel” ); 30: TaskLastModLabel.innerHTML = “Loading…” ; 31: _projDoc.getSelectedTaskAsync(function (asyncResult) { 32: taskGuid = asyncResult. value ; 33: document.getElementById( “taskGuidHF” ). value = taskGuid; //saves the task GUID to a hidden field to pass to the code-behind 34: document.getElementById( “hiddenTaskChangedButton” ).click(); //runs the CSOM calls in the aspx.cs file 35: }); 36: } 37:   38: // Get the GUID of the current project. 39: function getProjGuid() { 40: _projDoc.getProjectFieldAsync(Office.ProjectProjectFields.GUID, 41: function (asyncResult) { 42: projGuid = asyncResult. value .fieldValue; 43: document.getElementById( “projGuidHF” ). value = projGuid; //saves the project GUID to a hidden field to pass to the code-behind 44: } 45: ) 46: } 47:   48: // Task selection changed event handler. 49: function onTaskSelectionChanged(eventArgs) { 50: getTaskGuid(); 51: } 52:   53: // Add or remove a task selection changed event handler. 54: function manageTaskEventHandler(docMethod) { 55: manageEventHandlerAsync( 56: Office.EventType.TaskSelectionChanged, // The task selection changed event. 57: onTaskSelectionChanged, // The event handler. 58: docMethod // The Office.Document method to add or remove an event handler. 59: ); 60: } 61:   62: // Add or remove the specified event handler. 63: function manageEventHandlerAsync(eventType, handler, operation, onComplete) { 64: _projDoc[operation] //The operation is addHandlerAsync or removeHandlerAsync. 65: ( 66: eventType, 67: handler, 68: function (asyncResult) { 69: // code here runs after event has been registered (or failed) 70: } 71: ); 72: } The first time this code runs, it pulls the PWA URL (just like we did in URLConstructor.js) and saves it to one of our hidden fields, registers a client-side event handler to capture when a new task is selected, and starts the process of connecting to PWA and pulling the data we need, which is mostly done in the code-behind file. After each postback, we do not need to recapture the PWA URL, as our ProjectContext is maintained as a static variable. We need to make one quick tweak to TokenHelper.cs first – change GetRealmFromTargetUrl from a private method to a public method. The complete code for Default.aspx.cs is as follows: 1: using System; 2: using System.Collections.Generic; 3: using System.Linq; 4: using System.Web; 5: using System.Web.UI; 6: using System.Web.UI.WebControls; 7: using Microsoft.ProjectServer.Client; 8: using Microsoft.SharePoint.Client; 9:   10: namespace TaskLastModifiedAppWeb.Pages 11: { 12: public partial class Default : System.Web.UI.Page 13: { 14: public static ProjectContext projContext; 15: public static PublishedProject thisProj; 16: public Guid projGuid; 17:   18: protected void Page_Load( object sender, EventArgs e) 19: { 20: if (!IsPostBack) //set values of hidden fields if this is the first page load 21: { 22: projGuidHF.Value = “NA” ; 23: taskGuidHF.Value = “NA” ; 24: pwaUrlHF.Value = “NA” ; 25: } 26: } 27:   28:   29: protected void GetContexts() 30: { 31: var code = Request.QueryString[ “code” ]; //pulls the code token from the request 32:   33: string targetPwa = pwaUrlHF.Value; //pulls the PWA URL from where the Office app API stored it 34:   35: Uri targetPwaUri = new Uri(targetPwa); 36:   37: var tRealm = TokenHelper.GetRealmFromTargetUrl(targetPwaUri); 38:   39: Uri rUri = new Uri( “https://localhost:44301/pages/PostOAuth.aspx” ); //hardcoded link to redirect_uri 40:   41: var clientContext = TokenHelper.GetClientContextWithAuthorizationCode(targetPwa, “00000003-0000-0ff1-ce00-000000000000” , code, tRealm, rUri); 42:   43: projContext = GetProjectContextWithAuthorizationCode(targetPwa, “00000003-0000-0ff1-ce00-000000000000” , code, tRealm, rUri); 44:   45: projGuid = new Guid( “{” + projGuidHF.Value + “}” ); //loads the current project through CSOM 46:   47: var projects = projContext.LoadQuery(projContext.Projects.Where(proj => proj.Id == projGuid)); 48: projContext.ExecuteQuery(); 49: thisProj = projects.First(); 50: } 51:   52: protected void OnTaskChanged( object sender, EventArgs e) //determine the selected task’s last modified date 53: { 54: if (thisProj == null ) 55: { 56: GetContexts(); 57: } 58: 59: var taskGuid = new Guid(taskGuidHF.Value); 60:   61: var tasks = projContext.LoadQuery(thisProj.Tasks.Where(task => task.Id == taskGuid)); //load the selected task off of the project 62: projContext.ExecuteQuery(); 63: PublishedTask thisTask = tasks.First(); 64: string dateMod = thisTask.Modified.ToString( “D” ); //pull out the Modified field on the task 65: string timeMod = thisTask.Modified.ToString( “t” ); 66: TaskLastModLabel.Text = “The selected task was last modified on ” + dateMod + ” at ” + timeMod + “.” ; 67: } 68:   69: public static ProjectContext GetProjectContextWithAuthorizationCode( string targetUrl, string targetPrincipalName, string authorizationCode, string targetRealm,Uri redirectUri) 70: { 71: Uri targetUri = new Uri(targetUrl); 72:   73: string accessToken = 74: TokenHelper.GetAccessToken(authorizationCode, targetPrincipalName, targetUri.Authority, targetRealm, redirectUri).AccessToken; 75:   76: return GetProjectContextWithAccessToken(targetUrl, accessToken); 77: } 78:   79: public static ProjectContext GetProjectContextWithAccessToken( string targetUrl, string accessToken) 80: { 81: Uri targetUri = new Uri(targetUrl); 82:   83: ProjectContext projContext = new ProjectContext(targetUrl); 84:   85: projContext.AuthenticationMode = ClientAuthenticationMode.Anonymous; 86: projContext.FormDigestHandlingEnabled = false ; 87: projContext.ExecutingWebRequest += 88: delegate ( object oSender, WebRequestEventArgs webRequestEventArgs) 89: { 90: webRequestEventArgs.WebRequestExecutor.RequestHeaders[ “Authorization” ] = 91: “Bearer ” + accessToken; 92: }; 93:   94: return projContext; 95: } 96: } 97: } PageLoad() The f
irst time the page loads, we need to initialize the hidden field values. This enables us to not set them directly in Default.aspx (and thus lose their values after a postback) and lets the client-side code distinguish between a first run load and a postback. GetContexts() This code also only runs once, assuming the current project remains loaded. This handles the last part of the OAuth flow – we use the code token from OAuthAuthorize to generate a client context and a project context using methods in TokenHelper.cs, as well as slightly modified methods GetProjectContextWithAuthorizationCode() and GetProjectContextWithAccessToken(). OnTaskChanged() This first checks to make sure we have a project loaded from which to pull data. We then read the selected task guid from the hidden field, which was updated client-side before this method was called. We use Project CSOM to load the selected task from PWA and read its Last Modified field, which is then presented to the user in a readable format using the label on Default.aspx. Register the App ID and App Secret Since we are not submitting this app to the Office Store, we need to register it on our test tenant. On your tenant, navigate to https://[your PWA site]/_layouts/15/appregnew.aspx. Generate a new App Id and App Secret, set the Title to “TaskLastModifiedApp”, set the App Domain to localhost:44301 (or wherever the app code is running), and set the Redirect URI to match the redirect_uri token value in the oAuth URL created in URLConstructor.js. Hit Create, and then add the App Id and App Secret to web.config in your Visual Studio solution. It should look like the following when you are done, with your values for ClientId and ClientSecret: 1: 2:   3: 4: 5: 6: 7: 8: 9: 10: 11: Time to Test! To run the app, just hit F5 in Visual Studio, which will launch Project Professional. Make sure to connect to a PWA profile, then load a published project (or create and publish a new one). From a task view, select the Project tab in the ribbon, hit the dropdown for Apps for Office, and click TaskLastModifiedApp. The app will launch in a task pane on the right side of the screen. It’ll prompt you to trust the app, quickly load, and then display the last modified date and time of the selected task. Select a different task, and the data will update almost instantly. Wrap-Up In this blog post, you have learned how to create a task pane app in Project Professional that can display data from PWA that would not normally be visible in the client. The app uses SharePoint’s OAuthAuthorize page to request permissions from PWA and handle the authentication handshake between the app code and your online data. For more on working with OAuth, make sure to check out the relevant node in the SharePoint 2013 SDK. For more information on PWA programmability, check out the Project 2013 SDK . To learn more about writing task pane apps for the new Project, see this node in the Office 2013 SDK .

Yes, I am really really really looking forward to see you all next week at SharePoint Conference 2012 in Las Vegas #SPC12! Why you may ask? Well it will be the first Microsoft public event where we will showcase the newly released ( The New Microsoft Project reaches RTM! ) version of Project Online, Project Server 2013, Project Professional 2013, SharePoint 2013, etc. With a new release there is a ton to learn and we have plenty of content for you; starting with a cannot miss pre-SPC free 1 day training on Sunday November 11th , announced by my colleague Jan Kalis on the partner blog: The Best of Project Ignite at SPC12 . Following this packed one day event we have 12 sessions to date on your favorite PPM products, delivered by product experts from Microsoft, MVPs and customers during SPC12: Microsoft Project Sessions at SharePoint Conference 2012 And yes we will have a Project booth staffed by product experts from Microsoft, MVPs and marketing (!) where you can ask all your questions and get some surprises… But wait there is more … SPC12 this year will also have ton of networking opportunities, community initiatives and last but not least, great activities at night to relax and have fun. I’m arriving in Las Vegas Saturday, November 10th and will return to sunny Seattle on Friday, November 16th and I look forward to meet all of you (please leverage MySPC Meetings feature to schedule one)! Trust me, you do not want to miss this historical event… REGISTER TODAY to The Best of the New Project Ignite and SharePoint Conference 2012!

Enjoy! https://technet.microsoft.com/en-us/projectserver https://technet.microsoft.com/en-us/sharepoint https://technet.microsoft.com/en-us/office

Following last week’s first wave release: Microsoft Project Professional 2013, and SharePoint 2013 are available for download on MSDN ,  Microsoft Project Server 2013 is now available for download to MSDN and TechNet subscribes in your favorite language! Happy install… As a reminder there are plenty of Project 2013 resources available today: Product https://www.microsoft.com/project/en-us/preview/project-resources.aspx TechNet https://technet.microsoft.com/en-us/projectserver/fp123546 MSDN https:// msdn.microsoft.com/en-us/office/aa905469 Blog https://blogs.office.com/b/project/ Forums https:// social.technet.microsoft.com/Forums/en-US/category/project

Microsoft Support has release KB 2773530. This article provides troubleshooting guidance for Microsoft Office 365 and Microsoft Office 365 Preview users who receive error messages when attempting to sign in to Lync Mobile on an Apple iOS-based device when connected to a corporate Wi-Fi network using Active Directory Federation Services. To read the complete article, visit: Users cannot sign-In to Lync Mobile on Apple iOS-based devices because of certificate errors . Applies to Microsoft Office 365 Enterprise preview Microsoft Office 365 Small Business Premium preview Microsoft Lync Online preview Microsoft Office 365 for enterprises Microsoft Office 365 for small businesses Microsoft Office 365 for education

Microsoft Support has released KB 3761977. This article provides troubleshooting guidance for Office 365 Preview when the Lync Online Preview client displays a blank screen, and no controls are available . Applies to Microsoft Office 365 Enterprise preview Microsoft Office 365 Small Business Premium preview Microsoft Lync Online preview

I’ve been working on a recent case – and there have been some in the past that were very similar – where a customer had added users to a custom SharePoint group, then later found those same users were gone!  We had an idea what could trigger it but this time we managed to nail the root cause and will be requesting a fix from the product group.  But first a quick recap of how Project Server and SharePoint permissions play together – and it isn’t always nicely… Project Server will control the membership of its own SharePoint groups and also the individual permissions at project site level.  Project Server groups can be identified by the name – such as Project Managers Group (Microsoft Project Server).  Project uses these groups to give permission to the /PWA site – then for the individual project sites for each project the permissions are set for each user, and the permission level that user has is a Project Server one (such as Team Member (Microsoft Project Server).  Worth remembering that permission levels are not the same as groups.  Whenever Project needs to synchronize users, which could be after an Active Directory Sync, the editing of a category or group – or the editing of an individual user – then the process is that we remove everyone from the Project groups and directly on the sites then put back the people who should be there.  We don’t look to see who was there – we remove EVERYONE. So if you have added someone directly to a site, or added them to a Project managed SharePoint group, then unless they have a right to be there based on permissions and group/category membership they will be removed and not put back when a sync occurs.  It is nothing personal – we don’t even look to see who they are. The exception to this is the use of custom SharePoint groups – or basically a new SharePoint group that Project Server isn’t interested in.  If you add a new SharePoint group, and put users into it (regardless of whether they are in Project or not) then they will not be touched when a sync occurs.  Worth pointing out that this can give them access to sites – but unless they are in Project Server too they will not be able to get to /PWA. And now on to the bug… In some cases we were seeing that users would be removed from groups that we should not have been touching.  These were always Project Server users who had been added manually to another custom SharePoint group.  Closer examination of what was happening in the background showed that they were not just being removed from the group – but were actually being removed from the site – and so they would be taken out of all groups within that site too! Following an earlier hunch (Thanks ProjectHosts!)  that this was related to some specific Project Sites we were able to identify that the condition was triggered if a project site had been deleted but still existed in the list of sites on the PWA, Server Settings, Project Sites page.  Once we had an in-house repro it wasn’t difficult to trace the flow in debug and see what was going on.  The issue was that with the non-existent site our code was falling back to the top level – and because it was a top level it was then taking a path that removed the user from the site rather than just the web.  At the Project level this didn’t matter – as we would be putting them back again anyway – but we wouldn’t be putting them back in to any custom SharePoint groups, as we were not even aware that we had dropped them.  One slight variation that can trigger the same problem is for sites that do actually exist but the site starts with a space – so something like “https://server/PWA/ Site”.  Not sure how a site like this can actually get created – possibly it was migrated from 2007 – as the UI tend to stop you doing anything like this.  The workaround is pretty simple – use the Server Settings, Project Sites page, and the Delete Site option for any sites that really don’t exist – or if the leading space is the issue just correct the URL so the site and reference to the site don’t have this leading space.  As mentioned earlier we have a fix request in progress but unlikely to see this before the February 2013 Cumulative Update. If you have lots of sites then it might be tedious to click each one to see if it exists, so a couple of ways to detect the issue.  Firstly for the deleted sites a query against the published and content databases will help: Select PROJ_NAME from ProjectServer_Published.dbo.MSP_PROJECTS Where WPROJ_ISSUE_LIST_NAME NOT in (Select tp_ID from WSS_Content.dbo.AllLists where tp_DeleteTransactionId = (0x)) Or if like me you would prefer to stay away from the databases then the ULS logs give a clue if you know what to look for.  Turn Project Server, Administration to Verbose and you will see plenty of lines like the following as Project Server goes through the sites – filter for EventID of 8sv7 to get rid of noise: PWA:https://Server/PWA, ServiceApp:Project Server Service Application, User:i:0#.w|domainuser, PSI: UpdateSingleUserMembershipForWssSite: updating user i:0#.w|domainsyncuser. Project Uid – https://server/PWA/Sitename, workspace – a2496ce2-1d47-41d7-b4b5-39c4d7d0d970 However, one of these lines will not show the full URL to the project site but will stop at PWA, such as: PWA:https://Server/PWA, ServiceApp:Project Server Service Application, User:i:0#.w|domainuser, PSI: UpdateSingleUserMembershipForWssSite: updating user i:0#.w|domainsyncuser. Project Uid – https://Server/PWA, workspace – 0d8259d2-ed93-4508-b442-22f0ec3d3d7f You’ve probably noticed that we have the Projec Uid and workspace transposed, but the GUID after the word workspace will actually be the Project UID of the project causing the issue.  You can identify this by querying the database such as: Select ProjectName from MSP_EpmProject where ProjectUid = ‘0d8259d2-ed93-4508-b442-22f0ec3d3d7f’   Once you know the name then check out the site in Project Sites and either delete or correct the URL and all will be good.  A quick way to search the logs would be to use your PWA URL and search for “Project Uid – https://Server/PWA ,”.  For the adventurous amongst you who may have started troubleshooting and tried tracing the SQL I’ll mention a couple of the stored procedures you may have come across – just so the search engines might also find you the solution – we normally use proc_SecRemoveUserFromSiteGroupByLogin to remove the users from the Project groups, and proc_SecRemoveUserFromScopeByLogin to remove them from a web – but seeing proc_SecRemoveUserFromSite might be an indication that you are running in to this issue (although it would be normal, but not so usual, if the Project site also happened to be a top level site). This is probably also an issue with 2007 too, but happy to say that 2013 doesn’t appear to suffer from this same problem.  In 2013 we can also run purely with SharePoint permissions and without the project groups and categories – or you can use the familiar groups and categories.  Take a look at the permission articles under the Technical Reference at https://technet.microsoft.com/en-us/library/cc197638(v=office.15).aspx . One final point – another common request is that permissions should be given to Project sites based on a users RBS – in the same way that permissions to Projects themselves can be assigned.  Unfortunately this isn’t possible and isn’t something we will be changing with 2010. Thanks to Rob Cason for being my memory on a similar case from summer 2011, and thanks to my SharePoint colleague Daneil Aguiar for excellent troubleshooting that got us moving in the right direction.

The Office and SharePoint 2013 products are beginning to appear on the MSDN subscriber download pages – https://msdn.microsoft.com/en-us/subscriptions , including Project 2013 and SharePoint Server 2013.  I guess Project Server 2013 will be following shortly.  If you have a subscription then no time like the present to start looking at the new products.  Remember, the MSDN Licensing is per-user and is to design, develop, test, or demonstrate – not to be used for production use.  To give you a head start the best single link I can give you is to Christophe’s blog https://blogs.msdn.com/b/chrisfie/archive/2012/09/18/recent-content-about-the-new-project-project-online-project-professional-project-server.aspx where you will find plenty of other links to more content than you can shake a stick at.

Following the RTM announcement: The New Microsoft Project reaches RTM! the on-premise products are becoming available in different distribution channels starting with MSDN and TechNet subscribes as show below (and yes Project Server 2013 will also be available very soon…). Please check the Office RTM post for overall timeline for other channels: Office Reaches RTM! As a reminder there are plenty of Project 2013 resources available today: Product https://www.microsoft.com/project/en-us/preview/project-resources.aspx TechNet https://technet.microsoft.com/en-us/projectserver/fp123546 MSDN https:// msdn.microsoft.com/en-us/office/aa905469 Blog https://blogs.office.com/b/project/ Forums https:// social.technet.microsoft.com/Forums/en-US/category/project