Impact of Changing Server System Date to one Month Back(Win Server 2008 R2) - date

I have an application hosted on a dedicated Win Server 2008 R2.
The customer need past 3 months data to be entered into the application.We have only one method and that is setting the Server System Date to 3 months back data, till all the users completes updating the past data.
So my question is does setting the System Date to past date have any kind of impact in normal functioning of server or the network it's part of.
Please advice...

The server might automatically try to correct its time back to current time. If this server is apart of AD then there could be some issues. If it is apart of AD and is a GC then users might not be able to authenticate do to a time discrepancy. Updates via Windows Updates will also not work until the time is corrected. If this is the only way I would suggest getting it done as quickly as possible and setting the time back.

Related

How to change or inject date to Sharepoint application to test across months

Here is the situation:
I've got the application that requires different actions for different months. For example if I'll create a task that requires some actions for next 5 months I need some kind of method to keep jumping ti next months to confirm correct behaviour.
Usually I would just connect custom NTP for the server and than change date to whatever I want but this application works on Sharepoint online and as far as I know I can't do that (even if I'll it will affect all users not app under test only).
Another problem is that method should be easy and possible to explain or at least show to business during UAT.
Thanks in advance.

Distributed Recovery - can this be done without timeout?

We have a mail sender application, that receives a bunch of mails in one blob, and then puts all those mails into database. This can take up to ten minutes. During this process the state of the mailing is BUILDING.
When it is finished the state gets changed to READY.
When the server crashes (shouldn't happen of course) and restarts, it looks for all mailings with status BUILDING and marks them as ERROR. This happens, because we never want to send incomplete mailings.
Now we'd like to scale up using a second server. The recovery strategy above doesn't work here.
e.g. server 1 is BUILDING a mailing, and server 2 crashes and restarts. Now server 2 will see the BUILDING mailing and doesn't know if it's been aborted or if it's running on another server.
So what's the best recovery strategy for distributed services?
(We thought about some timeout mechanism, where the BUILDING server updates a timestamp every few seconds, and when some server reboots it checks if there's a BUILDING mailing that hasn't been updated for x minutes. Then it's highly possible that this mailing has been aborted.)
EDIT:
What I'd like to achieve: If some server restarts (after a crash or just because we added a new mailing server to the cluster), it should not mark mailings as ERROR if this particular mailing is actually being built (by another server).
Nice to have: If this would work without having to store server ids, because then it's possible to easily add and/or remove servers. Else it would not be possible to completely remove some server, because then there might be a BUILDING mailing with that particular server id. But this server got removed and will never get started again. Though the only server that could set the mailing to ERROR will be gone.
Add two things to your state tracking: a timestamp and the server working on it.
If a server starts up and sees anything in a building state for itself it knows it failed. Conversely, if it starts up and sees something in a building state for another server, it now has information that it's going to need to look at later to see if there's a problem that needs to be addressed. You need to worry about multiple servers restarting at the same time, so you can't just have a server grab all old bundles for all servers at startup.
Or you can just use a clustering service for your OS.

Lucene.net Server Farm / Multiple Servers

I haven't thought about this issue before as I was hosting the application on just one windows server 2008 and lucene.net stores the index on its local hard drive.
(Basically, every time, when a user post something or reply something, I update the index, so the search can return the latest result. Not sure if that's the best way to do it)
Now that we are going to need another webserver with a load balancer in front, I obviously can't have each sever index their own depends on where load balancer points to, as they will be out of synch.
One option for me is to hook up the two servers and map them to a shared server that stores the indexes, but is that a suggested solution?
How do you guys managed the parsing and indexing of lucene.net in a server farm environment?
Thanks a lot
You could seperate the Lucene index engine from your web application by creating a service that delivers the functionalities, something like a WCF or Rest service.
You can also use already existing search servers.
http://lucene.apache.org/solr/
http://www.elasticsearch.org/
The way we keep our load-balanced servers in sync, each with their own copy of Lucene, is to have a task on some other server, that runs every 5 minutes commanding each load-balanced server to update their index to a certain timestamp.
For instance, the task sends a timestamp of '12/1/2013 12:35:02.423' to all the load-balanced servers (the task is submitting the timestamp via querystring to a webpage on each load-balanced website), then each server uses that timestamp to query the database for all updates that have occurred since the last update through to that timestamp, and updates their local Lucene index.
Each server also stores the timestamp in the db, so it knows when each server was last updated. So if a server goes offline, when it comes back online, the next time it receives a timestamp command, it'll grab all the updates it missed while it was offline.

I need to programmatically set the date the OS returns to Java

I need to set the date that JVM would normally get from the OS.
Why? We have an app that interacts with a legacy app. All data on the legacy is always some date in the past (the client does reporting on a saved copy of live data (yesterday's data ) so as not to affect the response time of transactions on the live machine and demo's are done on dev machines, also some date in the past)
Our app needs to post transactions no later than the date on the legacy app. The legacy app lives on a different server. We have a process that returns the current date of the data and need to get the Java app to work entirely on that date.
We can't change the system date since a datawarehouse also runs on that box. So the only alternative is to change the date that JVM thinks it's getting from the OS.
Any ideas?
Own java agent should do the trick:
http://blogs.captechconsulting.com/blog/david-tiller/not-so-secret-java-agents-part-1
I suppose that intercepting System.currentTimeMillis() calls should be enough.

Is it possible to get a users timezone for an application hosted by Citrix XenApp?

I have a VB6 application hosted to users around the world through Citrix XenApp. I'm using the windows GetTimeZoneInformation call to find the time zone of the user in order to adjust some dates shown in the app (the dates come to the app in GMT). Unfortunately it looks like GetTimeZoneInformation gets the timezone of the Citrix server rather than the user running the application. Is there a Citrix based solution for this or am I going to need to change my implementation? This seems like a pretty big hole for Citrix hosted apps as I imagine you'd have the same problem with other localization settings.
What you ask should happen automatically: that applications do not get the server's but the client's time zone when asking Windows for the time zone. Here is a good description of how this works (PortICA, by the way, was a kind of early code name for XenDesktop).
If it does not work: client time zone support can be disabled, or any number of other things may have gone wrong. Check Citrix KB article CTX303498 for possible solutions.