So we have a SharePoint farm that is upon an AD forest, that forest is linked to other forests in a two-way trust.
Then, we have the people picker that is working quite fine and finding every user we try to find, regardless of what domain the user is on.
Now, I need to configure the people picker to find all users from current and future domains in the entirity of the relations BUT one of them. So, it must be a configuration where regardless of what domains, OUs, new or old 2-way trusts are configured, the people picker will find users for all domains BUT one of them.
I've tried to search for an LDAP query that'd do the job to feed to peoplepicker-searchadcustomfilter however could not find it or build it myself. Our AD expert could not get to it too.
I'd rather not use Peoplepicker-searchadforests because later on when they'd add a new domain, someone would have to remember that the people picker needed some configuration. I might be far away when that happens and someone would have to crack his head to find it.
So, from an LDAP Query standpoint, what'd you suggest? Much appreciated.
Related
In our website we want to launch country specific domains. so which one is preferred over another like add-on, parked domains or anything that i don't know.
our requirements is quite simple we want to publish country specific domain but the contents are mostly same except some price changes and unique features and/or languages for particular countries. so to take advantage of maintainability we want to use code from single directory in whatever choice we select.
right now we are in impression that we should go with add-on domain but i think we can also accomplish our requirements by using parked domains and detecting from which country domain the user is came from and render content accordingly.
Why not just go with a sub-folder like domain.com/us (for US for example) or maybe even a subdomain (us.domain.com [again, for the US version]) as explained here? Much better and cheaper alternative IMO than buying dozens of country-specific TLDs...
I have a requirement to find a way to archive subsites from a site.
When I say 'Archiving' I mean moving a subsite from one site to another so the end users can still access the subsites and check the history etc.
The main site is a Training site and the subsites are training courses, when these courses have ran there is no need for them to be sat under the training department site and I can envision it becoming confusing with too many of these subsites.
I know I can move them using structure and content in site admin but don't really want end users to be doing that after each course has ran ( we have had over 500 this year!)
Has anyone else faced a similar issue or have any advice to how they would go about it?
Many thanks
Is there a need to retain the subsites? If so, instead of moving the site, perhaps changing the way your users access the sites would be an easier way. You could set up a list with the current classes (assuming you don't have one already) and include a field in that list that links to the course's subsite. Create a view that shows only the current courses so the end users never see the other subsites.
If you don't need to keep the subsites, you should look into some kind of workflow that can kick off when a class expires that deltes the subsite. I'm pretty sure you can't create a workflow with Nintex or SharePoint Designer to move a site to another location, so you may need to code something with C#.
Trying to work out what to do in regard to a redirect of a new client real estate website.
We have no access at all to the old site and the url structure on new is forcibly different due to randomly generated property IDs (our system generates a different ID from old)
The old url structure is www.mydomain.com/property/view?=1111
The new url structure is www.mydomain.com/property/street-name/2222
My instinct is to do manual 301s for every property (about 6000), matching by page title, but sadly I cant as I have no access to the structure of the old website and despite spidering it numerous times I cant get a pull of all properties off.
If any could give me any advice on what best to do to avoid bad user experience and a google frying, would really appreciate it.
Thanks in advance.
Mark
It depends on what the 1111 is. If that corresponds to an MLS ID number (some sort of UID) then you should be able to use regex to get it to work. Most of the IDX vendors offer a way to grab listings via an MLSID.
If that 1111 is instead just a GUID of the previous IDX vendor, then you might be out of luck and would need to do everything manually.
I am relatively new to chef, so I may be missing something extremely basic. After much searching I am not finding what I need, so here goes:
In Chef, I have roles that are conflicting. I need for all servers of a certain type to have roleA, except for servers with roleB.
The best way I can think of to describe it is with an example:
syslog1, syslog2
web1, web2, web3
db1, db2
mail1, mail2
Every server within this environment(dozens) has a role called syslog_client, except syslog1 and syslog2, which need to have the role syslog_server.
The syslog-server and syslog-client roles conflict, because they configure the same pieces of software differently.
These are roles rather than recipes because they actually encompass several recipes.
I thought of doing something like this:
roles/base.rb:
name "base"
description "base configuration"
override_attributes(
)
default_attributes(
)
run_list(
"recipe[one]",
"recipe[two]",
"recipe[three]",
"role[uno]"
)
unless node[:roles].include?('syslog_server')
run_list('role[syslog_client]')
end
The problem there is that the node object does not exist at this point. I have thought about moving it into the recipe, but I could not come up with a good way to do it there either. I was able to use this in the base recipe:
unless node[:roles].include?('syslog_server')
node[:roles]+=['syslog_client']
end
This adds syslog_client to the roles attribute (or doesn't) correctly, but it never actually runs the syslog_client role.
I have considered moving syslog_client into a self-contained recipe rather than a role, and moving the role attributes to the environment. This would work, because then I can just call include_recipe "syslog::client". The problem there is that virtually all of our recipes are assigned from roles (not from other recipes), and I fear that making this change will create a one-off that will be hard to keep track of. Besides that, as I mentioned already, these are actually several recipes, so adding them as a single recipe is not ideal.
We have many different server types/roles in the environment I'm currently working in, and adding role[syslog_client] to them is feasible, but not ideal. With multiple people working on this, it seems likely that someone will forget to add the recipe to a new role.
In an ideal world, something like my first solution would be possible, because that allows us to keep our environment as consistent as possible. I am open to other options though.
So to wrap up, I think what I need is someone to tell me how to:
Make the first solution work. Add a role to a run list only if another role is not present
If I cannot have #1, I'd like opinions on the best way to achieve this using the ways I've listed or other ideas I have not thought of
Please let me know if I'm missing any details about our chef setup that will be helpful.
Disclaimer: The above example is really a very simplified version of what I'm actually trying to achieve. I'm not even working with syslog, but the company it is for is very security-conscious and would not be happy with details of their environment being posted publicly. I will be as detailed as I possibly can if I've left anything out and I need to add further info.
Extending what was said above what's the issue with creating two roles. A Client and a server
The Client role includes the base role and the client function. It will get applied to all servers through replacing references to 'base' with this role in all other roles. Meaning those roles still get base but get client as well.
The server is a stand-alone role which only applies to those servers and has the base and then the server role?
That way both client and server get the base role applied to them without duplicating the definition of what the base role is. You still manage that base role as you want but you use aggregation in the creation of roles?
When a new role is created the user won't start by adding base but instead adding the syslog_client role which gives them base as well.
To me that feels like the way Chef is pushing you with the creation of roles. What we have is 1 role that applies to all servers, some that apply to 1 subtype of servers but not anothers. That way our leaf role as in the one that gets applied actually consists of 4 or 5 other roles. What's common is modelled in a way that can be shared without the need for logic within?
The other option would be to add the client recipe to every node and the first exeuction step is to check the nodes role and if it says server just basically skip the recipe execution? Which would be the same as the logic which you were wanting to use to add the recipe but it would live in the recipe and control the execution?
unless node[:roles].include?('syslog_server')
#Do your client install
end
I tried using RoboForm but it's like Oracle - incredibly complex. We could never get it to share the corporate passwords but keep individual ones for each user.
Anyone know of a good login mananger?
We want one that has a shared company repository and individual repositories for each user for their person passwords. Preferably simple enough that there's only 5 - 10 options and only 1 password per user.
Have you looked at LastPass? It allows sharing individual passwords, but not a complete repository of passwords (at least as far as I know) so it may not fit your needs.