In a live system, where we have never had trouble deleting alerts (its been up and running for about a year now), we have come accross this for one user on 2 particular alerts, the problem is we cannot delete either alert using any account (The users, my Admin accounts, the sharepoint installer account)- We get an access denied error. Now, the 2 alerts are set on the same document, which is held withing library X and to parent folders (X/FolderA/FolderB/Document)- After setting up the alert FolderA (And all its contents) were moved to a new library (Library z), and the alert stayed where it is, set up on library x - To my understanding sharepoint should've deleted it when it was moved?
We've tried the following;
Recreating FolderA/FolderB/Document structure in x
Cutting and pasting FolderA back into X (so it had the same Guids)
But we still could not delete the alert using any of the accounts :S Does anyone have any idea how we might be able to delete the aler?
I got this problem with one of my main portal site. I escalate ticket with Microsoft. After doing so many trouble shootings. Finally we created new web application with same name, host address and attached the content db.
Problem resolved.
Related
Had my PC rebuilt due to a sign in issue with Azure. Ever since, I have been unable to sync a sharepoint site which is the main one I work in.
I go to the site contents folder online, select the main docuement library and click Sync on the top bar as shown below:
And every time, for this particular folder, I get this issue:
Other people are using and syncing this folder in exactly the same way without any problem. I can also sync any other folder without a problem, there is only this one important folder that seems impossible to sync. I can't create a new document library very easily as this will affect everyone. Any thoughts how to fix this?
Oh yeah and I've got the latest version of onedrive installed. In fact, when I click on that link, it takes me to an older version of onedrive which won't install as I've got a newer version.
Sometimes, the Microsoft Office Upload Center may affect the OneDrive for Business syncing with SharePoint library, it also may stop the SharePoint sync from progressing.
Try clearing cached files from Upload Center.
I've been working on a process that copies attachments to a couple places. Here's the basic outline:
User adds attachments to Power App
Power App adds those attachments to SharePoint list item
Power App/Automate adds those attachments to Freshdesk ticket
Power Automate copies attachments from SP to send confirmation email to user.
When FreshDesk ticket is closed, Power Automate reads attachments from Freshdesk notes and adds them to 1) an email to the original user and 2) the original SP list item.
Everything seemed to be working fine, but I am suddenly having issues specifically with Excel attachments. I can open them in their original OneDrive location, the emails they're attached to (although the Excel previewer doesn't always want to open), and in the FreshDesk ticket. I cannot open them in SharePoint. I just get an error that "This workbook cannot be opened."
These exact files were working fine before. I've cleared my cache, restarted by computer, and tried a different browser. Nothing will let me open them from my SP list. Help!
Edit: Solved, thanks to the folks on r/sharepoint! It's a Microsoft bug. You can view it in the M365 admin Center under Health. Description below.
SP411415 :
Title: Users can't open recently created Excel files from within SharePoint Online lists
User Impact: Users are encountering an error when attempting to open Excel workbooks from SharePoint Online lists.
More info: Affected users will see the following error:
"The workbook cannot be opened"
Current status: The fix has been submitted and we anticipate that deployment of the fix will start within the next one to three days. We're monitoring its progress to ensure the fix gets deployed and saturates throughout the affected environment.
Scope of impact: Any user hosted on the affected infrastructure will be impacted.
Root cause: A recent service update contains a code error within the previewing function which is causing an exception, resulting in impact.
Next update by: Thursday, August 11, 2022, 4:00 AM (9:00 AM UTC)
I have imported users from AD and keep syncing them for a while. Today two of users' display names have been changed on AD and SharePoint synced them correctly. Just to be sure, I checked users from User Profile Service App which looks OK. New names are appearing correctly.
Yet when I try to add a list item and select user from people picker, I get old user info. This also happens when I try to insert a list item programmatically.
Tried to delete users from SharePoint, however I still get same old users. Do you have any idea for solving this situation?
Thanks in advance.
I found the solution. There was an another User Profile Service Application which was not used and not properly configured. Weird point is, that malconfigured app was not listed on service applications. I found it by using Get-SPServiceApplication cmdlet and removed it. After removal, did a full synchronization and voila! Now I can get current information.
This is may be because entry in SharePoint's hidden user-list - User Information List.
Browse to this list - http://{SiteCollectionURL}/_catalogs/users/detail.aspx
Check for the display name of the users you have updated. If you see old user name instead of new/updated, delete these users from this list.
After this ask user to login to the same site again.
I have a configured a retention policy on a document library, the document should be moved to another location (Drop Off library) after certain amount of time. This doesnt seem to be working.
Please note that I have configured the Content organizer feature and "Send To" connections in Central Admin. I also have changed the trigger time for Information Policy and expiration policy job to run every 2 mins and 5 mins respectively.
Am i missing anything, because the functionality is not working and there is no error being thrown. All i can see is that the retention action is displayed as completed in "Compliance details" tab after sometime, but documents havent moved to drop off library. Also other retention action such as move to recycle bin work perfectly fine.
Please help.
Thanks in advance
If Move to recycle bin is working but Transfer isn't, I'm assuming your destination site is the same as the source. If so, this is not going to work because according to Microsoft support
It was as per design. If you try to move documents to a different location using Retention policy, you have to move it a library in a different site collection. Preferably ‘Records center‘ site collection. Main idea of Microsoft is to have one Archival or Records center site collection for the whole organization.
So, if you are trying to move documents after expiration to a library in same site or site collection, you can use a workaround to start a workflow on expiration date which moves the document to archival library.
Hope this helps. Source
To start with for investigation
1.There are two timer job services in Sharepoint 2010 ( it looks the same on 2013 as well) so ... "Information management policy" and "Expiration policy". check if these Job are working as desired for the web application. I understand it works partially on some instances. But I don't know if it is on the same webapp level.
Next can you check if these documents are checked-out to some one on the team or to a person who has left the firm which is very common sometime User Profile service may give you tickle by not syncing as desired.
If you have custom content type for which the the document is saved. then if the same content type exist on the destination folder ( drop off lib) where document to be moved.
I had a situation when the documents where located inside a folder (leaf) inside document library. Move of document expected a same folder on destination which was weird. But after changing folder name which had '(' symbol it worked.
I have also seen some instances of permissions to the folder for the timer job but, I did not have that experience.
Without actual settings on the retention policy I can only give only pointers. Therefore, please give bit more information about the retention policy setup if it is not confidential.
I have similar problem, and after lots of try and error I found up that I have a required column in the destination content type which wasn't required in the source content type. Just check it!
I have two reports that I need to build. One that has a dozen or so columns. The other has the same columns + 2 extra. The first one is aimed at employees the second with the additional columns is aimed at Sr. Management.
I have a windows group set up for the proper Sr. Mgt users.
I am using SQL 2012.
I've done some SSRS stuff, but not enough to say I'm competent to do more difficult reports.
The problem I'm having is that we do not want the employees to see the sensitive information in those two columns. Frankly, we don't even want them to know the existence of a different report.
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Option 2: I was thinking that I can use the UserID condition to hide the columns in the report and just create one report that differs depending on who was viewing. There are two issues that surfaced in my research. First, there is no facility for using Windows Groups instead of userid. That would mean I have to maintain the list of people inside the report and boy would that be a pain. And second, my understanding is that the export facility does not respect the column actions -- like hiding.
Am I making this too complicated? Is there an easier way to do this? With no other solution, so I need to put up another instance of SSRS for management and make them go back and forth?
Thanks for your time
Option1: You should not be able to 'browse' for folders unless the 'parent' level permission has an 'everyone' user set up to browse on the higher level. Set up a test account and RDP to a box you can use the test account on. Generally under 'Folder Settings' you set up permission and it cascades down until interupted. If you have a parent permission to browse and a lower one not to, they may be able to browse directories. You can ensure that the directory has ONLY dedicated users and the inherited settings are removed manually.
Option2: I would NOT do this. You will have a maintenance nightmare on your hands as you would have to determine in code who was what and update a list that would probably need to be updated somewhere in SQL or a service. As far as I know SSRS does not work with getting parameters and such directly from AD so you would have to code this time and again. For this reason and security context I would avoid this.
Option3: Set up a 'Subscription' to save the report to a file format(excel, pdf, word, etc) or email on a scedule and turn off permission for everyone but admins. If someone can still see the report or directory there is most likely a security context issue.
Option4: You can do a cheapy 'Hide in tile view' move that for most users will hide the directory unless they go to the URL directly and have access. Click on a folder then choose 'Folder Settings' then check 'hide in tile view' and hit okay. Directory is now gone for most part for regular users browsing in default mode.
I think we can just fix your problem, and avoid inventing a complicated and unnecessary solution:
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Chances are that either you set up the security settings wrong, or there's a bigger configuration nightmare to worry about. What you should do is create the folder, go into the settings of the folder, and edit the security (thus breaking inheritance from the parent folder). Before even adding groups, you need to remove anyone that doesn't belong - namely entries like "YOU\Domain Users" - that gives access to anyone on your domain. Once you've cleaned out whomever shouldn't have access, you can add the users/groups that should. Problem solved.
Now, if that doesn't work, then it would seem to me that your SSRS instance is somehow granting everyone sysadmin access - check the Site Settings to see what users and groups are in the System Administrator role. Investigate any groups thoroughly - is BUILTIN\Administrators a sysadmin in SSRS? Check the group locally on the computer - is there another blanket domain group shown there?
If everyone on your domain has complete access to the SSRS instance, then your goal of "hiding" things is impossible.