Forum Widgets
Latest Discussions
any possible to extend client ID and secret for app registered in SharePoint Online
Hi Team, is there any possible to extend client ID and secret for app registered in SharePoint Online? right now, we are not allowed to create any new app registration from SharePoint Online, only way is from Azure AD - App registration. how about the client ID and secret getting expired which is created earlier using SharePoint Online? is there any way like powershell script something to extend the validity of Client ID and secret for app registered in SharePoint Online? if yes, please share the detailed instructions and guidelines to perform. if no, then what is the possible way for next step of actions to do? you can reachout to me - mailto:email address removed for privacy reasons for further discussion about this issue. Thanks for the help!
Show Access and Confidentiality Message to External Users in a SharePoint Document Library
Is it possible to display the following text inside a SharePoint document library page so that it’s visible to external users when they open the shared link? Text to Display: Access and Use Access is restricted to authorized representatives and internal personnel. Users must not share their login credentials or grant access to any third party. Uploaded and downloaded documents must relate solely to the agreed scope of work Disclaimer Use of this site constitutes acceptance of these terms. Access may be suspended or restricted if security, confidentiality, or compliance risks are identified. Goal: I want this text to be clearly visible to external parties (for example, when they open a document library link to upload or view files).Origin and Synchronization of User Profile Properties in SharePoint Online
Hi everyone, I’m trying to understand exactly where the User Profile properties in SharePoint Online come from and how (or if) they are synchronized from Microsoft Entra ID (formerly Azure AD). I’ve extracted a complete list of the properties I see in my tenant, for example: AboutMe AccountName ADGuid Assistant CellPhone Country DelveFlags Department Fax FirstName HomePhone LastName Manager msOnline-ObjectId Office ... SPS-Responsibility SPS-Interests SPS-PictureExchangeSyncState SPS-UserPrincipalName WorkEmail WorkPhone I would like to understand: Which of these come from Microsoft Entra ID, Which are automatically synchronized to the User Profile Application (UPA), And which are local SharePoint or Delve properties, not connected to Entra. So far, I’ve only found this official documentation: About user profile synchronization in SharePoint Online However, it only lists a limited subset of properties (“The following Microsoft Entra user attributes are synced to the UPA…”), and it does not cover all the properties present in the UPA schema. I’m looking for a more complete or up-to-date reference — or at least an official explanation as to why there isn’t a public, full mapping between Entra ID and UPA. Does anyone know if there is an official complete list or a way to verify the actual source of each property (Entra ID, Exchange, Delve, local SharePoint, etc.)? Thanks in advance for any clarification or useful resources!
Sharepoint SitePage
Using Graph API . I want to access a specific Sitepage , I need to know the Sitepageid, based on /pages it will return all Page id within the Site, Is there a way to get the Sitepage id directtly based on the Sitepage name.aspx ? I want to detect files changes on that Sitepage and be able to downlaod the files from the sitepage ? How can we do that using Graph API I know we can detect files changed at the drive level within a site. I am looking for Sitepage can we do the same ?what API can be used ?Repository structure and CI/CD pipeline for SPFx WebParts
I am currently developing SPFx WebParts for a single SharePoint site. In our development repository, I have: A shared SPFx library Six separate WebParts, each in its own solution, organized as follows: library webparts webpart1 webpart2 webpart3 ... At the moment, on Azure DevOps, everything is managed in a single repository. To build and deploy a WebPart, I check Git for changes, build the WebPart, and then deploy it. I am considering whether, for the CI/CD pipeline, it might be more efficient to adopt a separate repository for each WebPart, allowing independent pipelines for each solution. In this scenario, I have two main questions: Is it considered a best practice to separate WebParts into distinct repositories? How should the shared SPFx library be managed in this case? I assume it would need a separate repository, but I would like guidance on the best way to integrate it with the WebParts. Thank you for your support.Having issues with SPFx isolation build lately
Hello We have a customer using an isolation version of our product and when we built a new version last week, it stopped working with below error. Unfortunately, once we install the new build, replacing with the older ones that used to work stopped working and showing the same error. "authorize:90 Unsafe attempt to initiate navigation for frame with origin 'https://xxxx.sharepoint.com' from frame with URL 'https://login.microsoftonline.com/..........'. The frame attempting navigation of the top-level window is sandboxed, but the flag of 'allow-top-navigation' or 'allow-top-navigation-by-user-activation' is not set" We would really appreciate how to handle these errors. Thanks Vijay
Error 'Cannot get value for projected field...' when users without email were set to the field
SharePoint List Setup I have a simple list with a Person field Approvers which allows multiple selections. One of the list items has a user set to the Approvers but the said user does not have email configured. REST API used https://xxx.sharepoint.com/sites/xxx/_api/Web/Lists(guid'xxx')/items/?$filter=ID eq xxx&$select=*,Approvers%2FEMail&$expand=Approvers REST API response Error { "odata.error": { "code": "-2146232832, Microsoft.SharePoint.SPException", "message": { "lang": "en-US", "value": "Cannot get value for projected field Approvers_x005f_EMail." } } } Graph API used https://graph.microsoft.com/v1.0/sites/xxx/lists/xxx/items?$filter=startswith(fields/Title, 'xxx')&$expand=fields($select=Title,Approvers) Graph API response Success "Approvers": [ { "LookupId": 1, "LookupValue": "User A", "Email": "" }, { "LookupId": 2, "LookupValue": "User B", "Email": "" }, { "LookupId": 3, "LookupValue": "User C", "Email": "******@outlook.com" } ] Question Is there anyway we can tell the REST API to react the same way as Graph API, instead of failing, return the data as-is?SharePoint Online Public CDN CSS File Not Updating
We updated a CSS file that is loaded on our site via the SharePoint Online Public CDN, but the changes are still not reflecting. It has already been 24 hours since the update. Steps we’ve tried so far: Saved the file Replaced the file Checked out and checked in Renamed the file and reverted the name Cleared browser cache Performed a hard refresh Has anyone else experienced this issue? How long does it typically take for changes to appear? I’ve seen some posts mentioning it can take days.
Connection was forcibly closed by TPC RST packet from Microsoft servers
We are experiencing intermittent but frequent connection terminations during communication with SharePoint Online via REST API. After several internal investigations, we were unable to identify any root cause on our end. We have observed unexpected connection resets originating from Microsoft servers, specifically during or after the TLS handshake. Packet trace including the TCP RST. This packet appears to be an unsolicited TCP RST sent from Microsoft side. 396 19.654862 SharePoint IP Client IP TLSv1.2 357 Application Data 397 19.655259 SharePoint IP Client IP TLSv1.2 1013 Application Data 398 19.655344 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 402] 399 19.655376 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 402] 400 19.655387 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 402] 401 19.655376 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 402] 402 19.655387 SharePoint IP Client IP TLSv1.2 1448 Application Data 403 19.655476 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 405] 404 19.655495 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 405] 405 19.656337 SharePoint IP Client IP TLSv1.2 1212 Application Data 406 19.656367 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 408] 407 19.656412 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 408] 408 19.656412 SharePoint IP Client IP TLSv1.2 1070 Application Data 409 19.657129 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 411] 410 19.657192 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 411] 411 19.657292 SharePoint IP Client IP TLSv1.2 992 Application Data 412 19.657325 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 414] 413 19.657435 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 [TCP PDU reassembled in 414] 414 19.657523 SharePoint IP Client IP TLSv1.2 992 Application Data 415 19.659729 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 416 19.660127 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 417 19.660216 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 418 19.660317 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 419 19.660318 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 420 19.661139 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 421 19.661235 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 422 19.662135 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 423 19.662212 SharePoint IP Client IP TCP 60 443 → Random Port [RST] Seq=... Win=0 Len=0 424 19.665417 Client IP SharePoint IP TCP 1514 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 425 19.766395 Client IP SharePoint IP TCP 1514 [TCP Retransmission] 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 426 20.367148 Client IP SharePoint IP TCP 1514 [TCP Retransmission] 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 427 21.167413 Client IP SharePoint IP TCP 1514 [TCP Retransmission] 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 428 21.179165 Client IP SharePoint IP TCP 1514 [TCP Spurious Retransmission] 443 → Random Port [ACK] Seq=... Ack=... Win=4194560 Len=1460 429 21.773431 Client IP SharePoint IP TCP 1514 443 [SYN, ECE, CWR] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM TLS Handshake Behavior: .NET-based applications on our server report the following exception: System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---] System.Net.Sockets.SocketException (10054): An existing connection was forcibly closed by the remote host. We have included packet traces showing: - Successful TCP and TLS handshakes - Encrypted application data sent by our client - Acknowledge packets from your server - Connection then abruptly closed by a TCP RST without any visible application-layer error Environment & Testing: - Operating System: Windows Server 2022 - Frameworks: .NET 6 / .NET 8 - Connectivity: REST API calls to SharePoint Online (no sync, no OneDrive, no hybrid setup), TLS1.2 used and set up based on Microsoft recommendations Observations: - Approximately 70% of API calls fail intermittently - Issue occurs across multiple SharePoint sites and folders - Affects all users (admin, regular users, etc.). - No firewall, hardware, or configuration changes have occurred on the affected server - Disabling security software had no impact - Temporary switch to IPv6 improved stability for ~24 hours before the issue returned - New development: - We moved some applications to a separate VPS — those are working correctly. - However, a similar issue has now started occurring on a completely different server hosted by a customer, indicating this may not be isolated to a single environment or IP. Is this expected behavior under specific policies (e.g., IP reputation, rate limiting, User-Agent filtering)? Could there be a misconfiguration or conditional access policy silently blocking some connections? Is this possibly related to throttling or regional backend issues? Thank you for any support in this case.
